Collaboration tool

ABSTRACT

A method for enabling collaboration between individuals to design, construct and maintain a building. The method comprises providing a network based computer system including at least one server and multiple clients. The multiple clients allow respective individuals to interact with the server. The server includes a machine-readable storage, which is encoded with software for execution by a CPU for allowing individuals at the respective clients to create, execute and manage projects associated with at least one of a design phase, construction phase and maintenance phase of the building. Each project comprises one or more events that are related to time. The method also comprises storing in the machine-readable storage events as they occur during execution of each project to create a building project database spanning at least the design phase and the construction phase and optionally the maintenance phase of the building.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a Continuation of and claims priority topending U.S. application Ser. No. 13/097,895, filed Apr. 29, 2011, whichclaims the benefit of U.S. Provisional Patent Application No. 61/329,890filed Apr. 30, 2010, the contents of which are hereby incorporated byreference.

FIELD OF THE INVENTION

The invention generally relates to a network based collaboration toolused to enable communication and collaboration between people working onindustrial, commercial or residential construction projects.

BACKGROUND OF THE INVENTION

Residential, commercial and industrial construction and buildingprojects can involve many different people and organizations, such asarchitects, contractors, electricians, accountancy firms, plumbers,painters, and material supply firms, among others. Although each personor group of people may not be known to each other beforehand, they mayall collaborate at some time in order to design, construct and maintainthe intended building.

Unfortunately, it is rare to achieve the level of collaboration neededin order to facilitate the design, construction and maintenanceoperations. This can lead to time delays and/or cost overruns, which arefairly commonplace in the construction industry. Substandard workmanshipand/or materials may sometimes be used to make up for these delays andoverruns, which may not be discovered until years afterwards and requireexpensive and/or lengthy corrective action.

While other industries have improved collaboration between people andorganizations through use of electronic communications and computersoftware, these gains have not yet been fully realized by theconstruction industry. Therefore, there is a need in the constructionindustry for an improved collaboration tool.

SUMMARY OF THE INVENTION

As embodied and broadly described herein, the present invention providesa method for enabling collaboration between individuals to design,construct and maintain a building. The method comprises providing anetwork based computer system including at least one server and multipleclients. The multiple clients allow respective individuals to interactwith the server. The server includes a machine-readable storage, whichis encoded with software for execution by a CPU for allowing individualsat the respective clients to create, execute and manage projectsassociated with at least one of a design phase, construction phase andmaintenance phase of the building. Each project comprises one or moreevents that are related to time. The method also comprises storing inthe machine-readable storage events as they occur during execution ofeach project to create a building project database spanning at least thedesign phase and the construction phase and optionally the maintenancephase of the building.

BRIEF DESCRIPTION OF THE DRAWINGS

A detailed description of examples of implementation of the presentinvention is provided herein below with reference to the followingdrawings, in which:

FIG. 1 is a high level representation of a collaboration system inaccordance with a non-limiting example of implementation of theinvention;

FIG. 2A is a high level block diagram of the collaboration systemillustrated in FIG. 1;

FIG. 2B is a more detailed block diagram of the components of one of theclients in the collaboration system illustrated in FIG. 1;

FIG. 3 is a more detailed block diagram of the software which determinesthe functionality of the system of FIG. 1;

FIG. 4 is a block diagram illustrating different user groups of the usercommunity of the system illustrated in FIG. 1;

FIG. 5 is block diagram illustrating different data categories of a userprofile database;

FIG. 6 is a more detailed block diagram of the community managementsoftware module;

FIG. 7 is more detailed block diagram illustrating different datacategories of a projects database;

FIG. 8 is a further detailed block diagram illustrating the datastructure of an events data category stored in the projects database;

FIG. 9 is a more detailed block diagram of the building project moduleillustrated in FIG. 3;

FIG. 10 is a more detailed block diagram of the user-interfacesub-module shown in FIG. 9;

FIG. 11 is a more detailed block diagram of project management interfaceshown in FIG. 10;

FIG. 12 is a flowchart of a process for performing registration at thecommunity of the system illustrated in FIG. 1;

FIG. 13A is a flowchart of a process for creating a project with thesystem illustrated at FIG. 1;

FIG. 13B is a flowchart of a process for assembling a project team thatis related to a particular step in the previous figure;

FIG. 13C is a non-limiting example of a user interface that could beused to search for prospective candidates to fill particular roles onthe project team;

FIG. 14A is a non-limiting example of a user interface that could beused to authenticate users of the system;

FIG. 14B is a non-limiting example of a user interface that would allowan authenticated user to access various functionality of the system;

FIGS. 15A to 15H represent other non-limiting examples of userinterfaces that may be available to the user;

FIG. 16 is a flowchart of a process showing one possible method of useof the system;

FIG. 17 is a block diagram of a variant of the building project module,including a knowledge builder module;

FIG. 18 is a more detailed block diagram of the knowledge buildermodule;

FIG. 19 is a block diagram of a knowledge database;

FIG. 20 is a flowchart of a process for analyzing project events andupdating the knowledge module.

FIG. 21 a block diagram of a variant of the building project softwaremodule, including a certification software module;

FIG. 22 is a block diagram of a certification parameters database;

FIG. 23 is a flowchart of a process for determining if a project meetscertification criteria;

In the drawings, embodiments of the invention are illustrated by way ofexample. It is to be expressly understood that the description anddrawings are only for purposes of illustration and as an aid tounderstanding, and are not intended to be a definition of the limits ofthe invention.

DETAILED DESCRIPTION

FIG. 1 shows a collaboration system 10 that includes two maincomponents, namely a suite of building project tools 12 and a communityof users 14 that is functionally linked to the suite of project tools12.

FIG. 2A shows one possible non-limiting form of implementation of thecollaboration system 10. The system 10 that is represented in thisfigure includes clients 16, a central node 18 and a network 100 thatserves to interconnect the clients 16 and the node 18. Although fourclients 16 are illustrated in FIG. 2A, it should be understood that anynumber of clients 16 could be included within the system 10.

Each of the clients 16 may be in the form of a computing device 110, ofwhich an example is provided in FIG. 2B. The computing device 110 may beequipped with a processor 120, a memory 130 and an input/output (I/O)interface 140. The aforementioned components of each computing device110 may be connected via an interconnection system such as copper oroptical connection.

The processor 120 within each of the computing devices 110 allow it toexecute program code that may be available from the memory 130, which isin the form of machine-readable storage. Executing the program codeprovides certain software services, some of which will be described inmore detail below. The memory 130 stores the program code, input and/oroutput to/from the processor 120, as well as the I/O interface 140.

The I/O interface 140 provides each of the clients 16 with the abilityto communicate with the network 100, among others. Where one or more ofthe clients 16 are non-mobile devices (e.g. computer workstations),their ability to communicate with the network 100 can be provided usinga wired connection, such as through the public telephone network. Whereone or more of the clients 16 are mobile devices, their ability tocommunicate with the network 100 can be provided using a wirelessconnection, such as via a WiFi, WiMAX or cellular connections. Forexample, a mobile laptop computer with a WiFi connection or an iPhone™or iPad™ with a cellular connection to the network 100 may be instancesof the clients 16. Other modes of connection between the clients 16 andthe network 100 (e.g., satellite links) are possible and would fallwithin the scope of the present invention.

Because the clients 16 and their potential configurations are believedto be well-known in the art, further details regarding them will not beprovided here.

The central node 18 is a computing device (or set of computing devices)that is in communication with the clients 16 via the network 100. Thecentral node 18 is itself comprised of a server 22 and a series ofdatabases 20.

Each server 22 in the central node 18 may itself be another instance ofthe computing device 110 comprised of the processor 120, the memory 130in the form of machine-readable storage and the I/O interface 140 thatare interconnected via connections. Since the architecture of thecomputing device 110 for the server is otherwise substantially similarto each of the clients 16 (which has been described with respect to FIG.2B), further details about central node 18 will not be provided here.

However, it is worth noting that the I/O interface 130 associated withthe central node 18 allows the server 22 (and therefore the central node18) to communicate with the network 100, and subsequently with each ofthe clients 16 that are also connected to the network 100. Inparticular, the I/O interface 130 in the server 22 may provide it(and/or the node 18) with the ability to communicate with the network100 via a wired or wireless connection similar to those described withregards to the clients 16.

The resulting relationship between the clients 16 and the one or moreservers 22 within the node 18 is generally similar to that of aclient-server relationship that is well-known in the art. As a result,no further details regarding the connection and/or relationship betweenthe clients 16 and the server(s) 22 will be provided here.

It is worth noting that the central node 18 may comprise one or moreservers 22. Each server 22 may run program code to provide thefunctionality of the software, or provide certain specialized services,such as authentication services for clients 16. When the servers 22within the node 18 are configured this way, it is worth noting that thegeneral functionality of the software provided by the node 18 to theclients 16 is generally determined by the program code when it iscollectively executed by each of the servers 22. As a result, thefunctionality provided by the node 18 is not limited to (or by) thenumber of servers 22 comprised within it.

In the case where the central node 18 contains more than one server 22,each of the servers 22 may be located at the same geographic location ordistributed geographically. Therefore, although FIG. 2A shows thecentral node 18 as a single entity, it is possible that the structure ofthe node is more distributed, such that the servers 22 within thiscentral node 18 may in fact closely resemble that of the clients 16. Insuch a case, the servers 22 comprising the central node 18 may beinterconnected via a public network (such as the network 100) or aprivate network (not shown) such as a dedicated local- or wide-areanetwork.

The central node 18 also comprises at least one database 20. Althoughonly one database 20 is shown in FIG. 2A, it is likely that the centralnode 18 comprises multiple databases 20. The databases 20 are providedfor data storage and are in communication with the servers 22 within thenode 18. The contents of and functionality provided by the databases 20will be described in more detail later.

The databases 20 may be stored on machine-readable storage that isaccessible to the processor and/or memory within the servers 22. Incertain cases, the databases 20 may be stored in the local memory of theservers 22, while in other cases, the databases 20 may be storedremotely to the servers 22, such as on machine-readable storage of ahard disk or similar device.

Like the servers 22, the set of databases 20 within the central node 18may be co-located at the same geographic location, which may be the samelocation as the one or more servers 22. Alternatively, the databases 20may be located at different geographic locations. Therefore, althoughFIG. 2A shows the central node 18 as a single entity, it is possiblethat the structure of databases 20 within this entity may in factclosely resemble that of the clients 16. In such a case, the databases20 comprised in the central node 18 may be interconnected via a publicnetwork (such as the network 100) or a private network (not shown), suchas a dedicated local- or wide-area network.

The network 100 that serves to interconnect the clients 16 and thecentral node 18 in a client-server relationship may be any suitablenetwork including, but not limited to a global public network, such asthe Internet, a private network and a wireless network. In certaincircumstances the network 100 may comprise certain elements of all threeaforementioned networks, but the network 100 may be thought of as theInternet or any other equivalent network.

FIG. 3 shows a high-level block diagram of software components of thecollaboration system 10 that result from the processing and execution ofcertain program code by the processors in the servers 22 of the centralnode 18. The software components shown include a projects module 302 anda community management module 304. A building projects database 312 anda user profile database 314 communicate with the projects module 302 andthe community management module 304.

The projects module 302 provides certain functionality typically relatedto managing individual projects, which may be related to building orconstruction projects, among others. The functionality provided by theprojects module 302 may include among others:

-   -   creating and storing project-related data, such as activities,        tasks, timelines and work assignments related to a particular        project;    -   managing access to project-related data to ensure that        project-related data is kept secure;    -   managing permissions for individual users to create, modify        and/or delete such data;    -   processing project-related data to derive certain information        related to a project as a whole, such as the overall project        status; and/or    -   processing project-related data to derive certain information        related to a particular aspect of the project, such as a list of        tasks or activities that must be performed on a certain date        (and/or the persons assigned for those tasks).

The community management module 304 provides certain functionalityrelated to the user community 14, and more particularly to assisting oneor more individual users within this community to work on a building orconstruction project. More specifically, the community management module304 can assist individual users to communicate with other users andobtain information relating to a construction or building project. Thefunctionality provided by the community management module 304 mayinclude among others:

-   -   managing user profiles for individual community members, which        may include the creation, maintenance and deletion of such        profiles;    -   providing facilities for enabling private communications between        two or more user community members, such as via email, text/chat        or Voice-Over IP (VoIP) telephone calls;    -   enabling public communications between one or more members of        the user community 14 and a group of such members, such as by        posting to (and/or replying to a post) a forum or community of        practice;    -   allowing searches of the user community 14 to be performed by a        member in order to find members that meet or fulfill certain        criteria, such as being within a certain distance of the member        who initiated the search; and/or    -   enabling searches of the forums/communities to be performed in        order that a member can find all public communications that        fulfill certain criteria, such as posts regarding the        installation and/or maintenance of a certain piece of equipment.

It will be appreciated that the functionality listed for the projectsmodule 302 and the community management module 304 is non-exhaustive asother possibilities exist and would fall within the scope of the presentinvention.

FIG. 3 also illustrates that the modules 302 and 304 are interconnected,such that information from the projects module 302 can be passed to thecommunity management module 304 and vice-versa. In certain non-limitingembodiments, this relationship may establish or support a particularhierarchy between the modules 302 and 304. For example, the communitymanagement module 304 may support the projects module 302 by allowingproject-specific data within the projects module 302 to be sharedbetween users of the user community 14 involved in this project viatheir user profiles, which are provided by the community managementmodule 304.

Alternatively, the projects module 302 may support the communitymanagement module 304 by allowing certain project-related informationabout projects that involved a particular user community member to beviewed by other members of the user community 14 who were not involvedwith such projects. For example, it may allow individuals of thecommunity 14 to identify other individuals within the community 14 whohave certain valuable expertise.

During execution, the projects module 302 and the community managementmodule 304, communicate with and process data that is stored in thedatabases 22. In particular, the project module 302 communicates withthe (building) projects database 312 that stores project-related data.Likewise, the community management module 304 communicates with the userprofile database 314 that stores user profiles for the user community14.

FIG. 4 shows a relationship between the user community 14 and the userprofile database 314 that is accessible to the community managementmodule 304.

In particular, the user profile database 314 may be seen as beingcomprised of user profiles 340 _(N), wherein the database 314 at anypoint in time contains a set of user profiles 340 ₁ to 340 _(N-1). Eachprofile in the set of user profiles 340 ₁ to 340 _(N-1) is typicallyunique and encodes information related to a corresponding user of theuser community 14. This set of user profiles can be organized within thecollaboration system 10 in certain ways that will be described shortly.

FIG. 5 shows a non-limiting embodiment of a user profile in the set ofuser profiles 340 ₁ to 340 _(N-1). In this embodiment, the user profileis comprised of contact and profile data 510, a set of links to theuser's active building projects 520 and a set of links to the user'scompleted building projects 530, among others.

The contact and profile data 510 includes personal and biographicinformation related to the user that is not necessarily related to aparticular project. For example, the data 510 may include a particularuser's:

-   -   contact details (e.g., name, address and phone numbers);    -   authentication details (e.g., email address and password) that        can be used by the system 10 to authenticate the user;    -   an external email address to which the user wishes communication        to be directed and which may also function as an authentication        detail (e.g., the user's email address); and/or    -   a photo of the user.

The contact and profile data 510 may also include a ‘profile’ sectionthat includes, among others:

-   -   information related to the user's education (e.g., the        educational level reached by the user);    -   any professional associations to which the user currently        belongs or has belonged;    -   groups to which the user is a member, such as named groups        (which are described below);    -   a list of relevant work experience;    -   any external or professional certifications received by the        user;    -   information relating to any special skills and/or abilities        possessed by the user;    -   an indication of any particular types of work the user prefers;        and/or    -   a list of references who could be contacted to validate        information in the user's profile.

The set of links 520 and 530 provide additional information related tothe contact and profile data 510, and namely the work experience withinthe user profile section. In particular, the set of links to activebuilding projects 520 and the set of links to completed buildingprojects 530 serve to show projects in which the user is eithercurrently involved, or has been involved in the past, both of which arealso likely listed in that user's work experience.

The term ‘links’ in the set of links to active building projects 520 anda set of links to completed building projects 530 should be interpretedin a broad functional sense, rather than a hyperlink to a particularURL. For example, a particular link to a completed building projectwithin the set of links 530 may be a link to the contact details for acertain person involved with that project, rather than to informationrelated to that project.

Because each profile of the set of user profiles 340 ₁ to 340 _(N-1)likely contains the same or similar type of information, the userprofile database 314 can be queried to identify and/or organize users inthe user community 14 according to certain relationships. In the contextof a building project for example, certain users in the community may bemembers of professional associations, such as users who are architectsor civil engineers.

Optionally, the collaboration system 10 may not attempt to organize theuser community 14 beyond providing certain facilities to search thecommunity 14. For example, the system 10 may provide a search tool thatallows a first user to find user profiles for other members of thecommunity 14 that meet certain criteria, such as belonging to the sameprofessional association or being located at a somewhat proximatedistance to each other. Such search tools will be described in moredetail below.

However, members of the user community 14 may organize themselves intogroups, which may be named or remain unnamed. For example, all of theusers who are collaboratively working on a project form a group,although this is more generally referred to as a “team” or as a “projectteam”. In such cases, the group itself typically remains unnamed but itsmembers are known to each other through their involvement in theproject.

Alternatively, members of the user community 14 may organize themselvesinto so-called ‘named’ groups that may represent formal affiliations ofusers within the community. The affiliations represented by named groupsmay represent certain personal and non-personal affiliations, including:

-   -   corporate- or business-related affiliations, such as those        represented by businesses, corporations or other        non-governmental organizations (e.g., Habitat for Humanity);    -   professional affiliations, such as members of professional        associations (e.g., members of the Green Building Initiative);    -   educational affiliations, such as members who attended the same        university, trade school or training course;    -   geographic affiliation, such as members who are located in the        same city, region, state, province and/or country; and/or    -   personal affiliations, such as members who play a particular        sport (e.g., golf or hockey) or who share a particular hobby,        among others.

It will be appreciated that the above list of affiliation types that canbe used to form named groups in the user community 14 is non-exhaustive.Other types of affiliations may exist and would fall within the scope ofthe present invention.

It may be appreciated that users within the community may simultaneouslybe affiliated with one or several named and/or unnamed groups, such asmembers of multiple project teams, corporate organizations and/orprofessional associations, among others.

For example and with respect to FIG. 4, it may be seen that an instanceof the user community 14 (as embodied within the user profile database314) contains a plurality of user profiles 340 _(i), some of which areaffiliated through the following named and unnamed groups:

-   -   Named group A 410 represents a first company comprising the user        (profiles) 340 ₇, 340 ₃₅ and 340 ₉₈;    -   Named group B 420 represents a second company comprising the        user (profiles) 340 ₄₇, 340 ₅₂, 340 ₉₉ and 340 ₁₁₀;    -   Named group C 430 represents members within a professional        association comprising the user (profiles) 340 ₇, 340 ₂₆, 340 ₆₂        and 340 ₈₄;    -   Unnamed group D 440 represents a project team comprising the        user (profiles) 340 ₇, 340 ₃₅, 340 ₄₇, 340 ₈₄ and 340 ₂₄₅.    -   Unnamed group E 450 represent two (2) users who are members of        the same project team who are both working on the same task.

Based on the above, it will be appreciated that the user represented byuser profile 340 ₇ is affiliated with three (3) groups in the usercommunity 14: the named group A 410 (as an employee of his or hercompany), the named group C 430 (as a member of a professionalassociation) and the named group D 440 (as a member of the projectteam). Similar affiliations exist for certain other users in thecommunity 14, as is shown by FIG. 4.

In addition to professional associations and/or business organization,profiles in the set of user profiles 340 ₁ to 340 _(N-1) may be groupedsuch as to be searchable by other types of relationships between membersof the user community 14 including, among others:

-   -   users who perform similar tasks (e.g., Heating, Ventilating and        Air Conditioning (HVAC) maintenance engineers or CAD        technicians);    -   users who have the same educational background (e.g., went to a        particular university or college);    -   users who have similar skills and/or work experience (e.g.,        maintenance experience with a particular building system);        and/or    -   users who are living (or working) within certain geographic        locales (e.g., those living and/or working within 100 km of        Montreal, Canada).

In addition to the user profiles being searchable according to the aboverelationships, the community management module 304 may create (orfacilitate the creation of) sub-groups or sub-communities that are basedon the above relationships. For example, the user profiles of a group ofusers that have experience with a particular HVAC system may beautomatically grouped by the module 304 to form a particular sub-group.The sub-group may then be provided with certain communications means(e.g., a forum) that allow members to communicate in order to shareinformation and/or store relevant information for future use.Advantageously, provision of such forums may allow useful, yet ‘tacit’information that resides with a single person to be shared among thelarger sub-group.

Alternatively, a group of users in the user community 14 could use thecommunity management module 304 to form a sub-group that would be basedon their own custom criteria. For example, users within the community 14who are alumni of a particular school (e.g., architects who graduatedfrom the McGill University Faculty of Architecture) could form their ownsub-group in order to stay in touch, network and/or arrange socialfunctions, among others.

FIG. 6 shows the components of the community management module 304. Thecommunity management module 304 is typically comprised of aregistration/authentication sub-module 610, an email managementsub-module 620 a forum/community sub-module 630, a search sub-module 640and a tagging sub-module 650.

The registration/authentication sub-module 610 is invoked when a memberof the user community 14 wishes to create, manage or delete their userprofile within the set of user profiles 340 ₁ to 340 _(N-1). Forexample, in the case where a user wishes to create a new profile, theregistration/authentication sub-module 610 presents a user interface(UI) to request that the user provide some basic information abouthimself or herself (e.g., name, email address) as well as a password inorder that the new user profile can be created.

Once a user profile exists within a set of user profiles 340 ₁ to 340_(N-1), the registration/authentication sub-module 610 may also beinvoked in cases where the user may want to change the informationwithin his or her particular profile. For example, the sub-module 610may prompt the user to enter his or her password in order to confirm anysubstantive changes to the user profile. The same sub-module may also beinvoked when a user decides to remove their user profile from the set ofprofiles 340 ₁ to 340 _(N-1), such as in the case where they retire orchange industries.

The email management sub-module 620 is invoked when a user wishes to seeemail communications sent to him or her by other members of the usercommunity 14 via the collaboration system 10. The sub-module 620 mayprovide the user with a UI (to be described below) that allows them tobrowse, read, reply and/or forward individual emails, among otherfunctionality.

The email management sub-module 620 may also allow the user to organizehis or her email communications, such as by organizing certain emailsinto related folders or establishing rules that automatically categorizeincoming emails. In such a case, the sub-module 620 may also enablecommunications between the user and any communities to which the userbelongs, such as allowing the user to send an email to a communityand/or organizing replies from the community into a particular folder.

In certain cases, communications between members of the user community14 enabled by the collaboration system 10 may include types ofcommunications other than emails, such as online chats, voicemails orrecordings of VoIP calls. In such cases, the email management sub-module620 may also provide the user with the ability to review and/or organizesuch communications in addition to email.

The community/forum sub-module 630 is invoked when a user chooses toparticipate in a sub-group forum. The sub-module 630 may present a UI tothe user that is likely similar to that provided by the email managementmodule 620 but is tailored for forum communications. For example, thecommunity/forum module 630 may provide a separate interface so that auser can more easily search and/or follow threaded email discussionsthat have occurred within a particular sub-group forum.

The community/forum sub-module 630 may also be used in the case where aparticular sub-group maintains a website or knowledge base for the usercommunity 14 in general. For example, a particular sub-group related toan open-source building maintenance system may operate a Wiki that listsuseful commands, tips and tricks that are not provided in the system'suser manual. In a case, the sub-module 630 may provide functionality fora member of the sub-group to update the Wiki in case of new materialand/or corrections to existing Wiki content.

The search sub-module 640 may be invoked when a user performs a searchof the set of user profiles 340 ₁ to 340 _(N-1) in order to locatemembers of the user community 14 that meet certain criteria.

The search sub-module 640 provides a UI (to be described later) thatallows a user of the collaboration system 10 to identify and furtherdefine certain attributes of the user profile upon which the set ofprofiles 340 ₁ to 340 _(N-1) is to be searched. For example, a user maywish to identify other members of the user community 14 that belong to aprofessional organization and have experience with a certain type ofelevating device, such as an elevator, escalator or moving sidewalk.

The search sub-module 640 may provide certain so-called ‘default’searches that allow a user to search based on pre-determined criteria,such as proximity to the user's recorded (or current) location. Forexample, the sub-module 640 may allow a user to locate other usercommunity members 14 that are within 5, 10, 15, 25, 50, or 100 km of hisor her current location.

The search sub-module 640 may also provide a user with the ability tocreate more advanced searches that search multiple, customized criteria.For example, the sub-module 640 may allow a particular user to identifyall other users who are within 15 km of his or her location that havebetween 5 and 10 years of experience installing and maintaining stormwater maintenance systems manufactured by a particular company who havealso been involved in the design phase of a construction project.

In a non-limiting embodiment, the tagging sub-module 650 may be used toperform certain functions that relate to two or more entities within theprojects database 312 and/or the user profile database 314, as well asbetween these databases. In another non-limiting embodiment, the taggingsub-module 650 may also be used by a first user to ‘tag’ or assign acertain rating that indicates his or her satisfaction with the work of asecond user. Both embodiments of this module will be described below.

In one non-limiting embodiment, the tagging sub-module 650 can be usedto assign a ‘tag’ to one or more items in the projects and/or userprofile databases 312 and 314. This tag typically is used to remind auser of a relationship between a first item and a second item that issomehow related to the first item but is otherwise separate from it.

For example, assume that a building project for an office building onwhich the user is collaborating includes a three-dimensional (3D) mockupof the building that will be available on the building's website. It isexpected that users will travel in (i.e., walk or fly through) thebuilding represented by avatars so that they can simulate what visitingand/or working in the building may be like.

Further assume that production of the 3D mockup may involve severaldifferent members and/or groups within the user community 14, such asthe architect working on the project, a group of draftsmen working underthe architect who are responsible for creating the 3D mockup, aninterface designer who is working to create the interface that willallow the users to manipulate their avatars, a web designer who iscreating the necessary code to run the simulation, and a systemsadministrator who will install and maintain the servers used to run thesimulation.

Each of these users may create a tag (which may be in the form of a textstring or icon) that when applied to some element in the projectsdatabase 312 and/or the user profiles database 314, relates that item tothe tag. A tag can be viewed at a later time so as to allow the user toreview one or more of its associated elements.

For example, the architect may create a tag titled “3D-Simulation” forthis particular aspect of his office building project. The architect maythen apply this tag to the following in the system 10:

-   -   the user profile 340 _(i) of each team member involved in the 3D        mockup;    -   the named group representing the draftsmen working on the        project;    -   all communications (e.g., email messages or embedded video        clips) regarding this aspect of the project;    -   all tasks and other events related to the 3D simulation, such as        scheduled planning meetings and/or testing of the mockup by        selected so-called ‘beta users’.

It will be appreciated that the above list is non-exhaustive as otherelements in the system 10 could be tagged by the author that would fallin the scope of the present invention.

Once an item is tagged with the 3D-Simulation tag, certain of itsinformation (such as metadata) is updated to indicate that thisparticular tag has been applied to it. At a later time, the system 10,and more specifically the tagging sub-module 650 (or alternatively, thesearch sub-module 640) may search for and display these items based onits tag.

For example, assume that a dispute arises between the architect and theweb designer about the background image(s) that should appear when anavatar looks out of a window in the office building. Rather than searchthrough the entirety of items in the projects database 312 and/or userprofile database 314, the architect can review the items that weretagged with the 3D-Simulation tag. Assuming that the architect wasdiligent in his tagging, viewing these tagged items may allow him toidentify the particular item (such as an email exchange or an uploadedset of images) that identify the correct images that an avatar should‘see’ when looking out of a window.

A set of tags relating to a project that is stored in and/or used by thetagging sub-module 650 may exist at an individual user level, at aproject level and/or at a system level. In general, each user has theability to create tags that are particular to his or her own projects.This allows the user to create and organize his or her own tags based onwhatever organization scheme is most useful to them. For example, thearchitect who is working on the 3D mockup may call his tag“3D-Simulation” whereas the web designer working on the same project mayuse a “100 Bank St. Building flythrough” as her tag.

If the project team members wish to collaborate, however, a set ofproject tags may be implemented through the tagging sub-module 650. Thisset of project tags may be available to all project team members andused to tag items for others on the project team to view. For example,the project tags may include the names of all companies (i.e., namedgroups) as tags.

For example, assume that a particular building project involves twomajor contractors, namely ABC Corp. and XYZ Ltd. who each areresponsible for different aspects of the construction. Further assumethat each contractor is supplying 5 people to the project and that eachperson's profile is tagged with that contractor's tag. If the projectteam displays a simple list of the project team, each user from eachcontractor can be further tagged to identify his or her company.Therefore a person viewing the tags for each contractor will be able toidentify the 5 particular users from that company.

Although the above example is simplistic, it shows the value that acommon set of tags implemented for a project may have to enhancecollaboration. For example, if a third contractor was brought in to workon yet another aspect of the project, he or she could quickly identifywhich person on the project team was from each contractor via theirtags. This may allow the third contractor to identify the person on theproject team who may be responsible for a certain contractor's tasks oractivities that relate to or interface with his or her activities on theproject.

A set of system-level tags may also be provided by the taggingsub-module in addition to those at the individual user and/or projectlevels. Such system-level tags may include common terminology oracronyms that are used throughout the industry. For example, a set ofsystem-level tags that may be used in the building construction industrymay include:

-   -   HVAC (acronym for Heating-Ventilation-Air Conditioning);    -   Charette (term used to identify meetings between a building's        designer and those responsible for its construction); and/or    -   LEED® (acronym for Leadership in Environmental and Energy        Design).

Of course, it will be appreciated that the above list of prospectivetags is non-exhaustive as other entries exist and would fall within thescope of the present invention.

It will be appreciated that although all users may be able to access andadd content to a set of tags provided by the tagging sub-module 650, themanagement of such tag sets may differ depending on the level at whichthe tags are provided. More particularly, management tags other thanthose at the individual user level may be restricted from individualusers. For example, a certain project team member may be responsible forall project tags, and only he or she can create or remove tags from thisset.

System-level tags may be further restricted in that only certain membersof the user community 14 can effect management of these tags. Forexample, members of the user community 14 may need to request additions,modifications to, or deletions from the set of system-level tags fromcertain other members of the community 14; no modifications could bedone by the user himself or herself. Furthermore, the requestedadditions or modifications may need to be considered, debated andapproved by a group of members (e.g., a tag editorial board) beforeadditions, modifications and/or deletions to the system-level tags areeffected. In this way, sets of tags designed for use by a plurality ofusers can be managed in a way that ensures that these users will be ableto recall and/or collaborate using these tags.

It may be recalled that the concept of a ‘tag’ in the tagging sub-module650 was two-fold in that a tag could be used to identify content forlater recall and/or collaboration, as well as using a tag to rate thework of members in the user community 14. The above description of thetagging sub-module 650 has described a non-limiting embodiment thatprovided for the recall and/or collaborative aspect of a tag. Thedescription below presents a non-limiting embodiment of the tag thatprovides for a ‘tag’ to be applied in order to rate the work of a userfor the user community 14.

In particular, the tagging sub-module 650 may allow the work of a firstmember in the user community 14 (and more specifically, his or her userprofile stored in the community database 314) to be rated by and/or havecomments from other members of the community 14 be seen. For example, ifa particular engineer or technician is known to do very good work, thisuser's clients, colleagues and/or co-workers may ‘tag’ this user'sprofile to indicate this to other users in the community 14 that havenot worked with this engineer or technician.

It will be appreciated that a “tag” may include any indication or ratingof a particular user's past or current work by other users, including:

-   -   graphical indicia (e.g., checkmarks, stars,        thumbs-up/thumbs-down);    -   textual comments (e.g., “Very thorough and corrected mistakes        early.” “Very easy to work with—would use again.”; and/or    -   a numeric score, which may be calculated based on certain        factors, including the indicia and/or textual comments and act        as a proxy for satisfaction, among others.

The tagging module 650 provides a UI that allows one or more members ofthe user community 14 to apply such tags to the user profile of anothermember. These tags may allow the community 14 as a whole to identifyparticularly good members and therefore reward them for their effortsthrough recognition. (Alternatively, the tags may also allow thecommunity 14 to identify particularly bad people who should be avoided.)

For example, assume that a freelance landscape architect named Bob Smithis a member of the user community 14 and performs work on a project withother users in the community. During his work on this project, Bob isseen by his fellow co-workers as both easy to work with, as well assomeone who shares his knowledge freely with other architects andengineers. When Bob's work on the project is finished, his fellowco-workers use the UI provided by the tagging module 650 to indicatetheir satisfaction with his work, such as by using visual indicia (e.g.,gold stars), by leaving comments (e.g., “Bob was outstanding in ourproject! We would love to work with him again . . . ”, and/or byproviding input to a scoring system that improves Bob's overall‘satisfaction score’ within the community.

It will be appreciated that the formula used by the tagging sub-module650 to calculate a numeric score that provide a proxy for the level ofsatisfaction with a user's work may be based on one or more inputs. In asimple example, the sub-module 650 may simply compare the number ofpositive satisfaction indicators (e.g., thumbs-up icons) against thenumber of negative dissatisfaction indicators (e.g., thumbs-down icons)to calculate a general satisfaction index.

Alternatively, the sub-module 650 may provide a UI that allows othermembers of the user community 14 to rate a particular user's work alongseveral different dimensions, such as his or her punctuality, efficiencyand/or quality. Such rating may be based on a scale, such as a 5-pointscale where 1 represents total dissatisfaction and 5 represents totalsatisfaction (or vice-versa). The values for each dimension contributedby one user may then be averaged with similar values contributed byother users to generate an average value for each dimensionindividually, as well as to generate a total satisfaction value for theuser as a whole. Such an approach can allow the work of a certain userto be viewed by other users along a range of different dimensions, suchas punctuality, efficiency, quality, general perceived value and/or adesire to work with again.

Besides the ability to register the user community's 14 satisfaction (ordissatisfaction) with the work of a particular user, the taggingsub-module 650 may also provide so-called ‘social networking’functionality for the collaboration system 10. In a non-limitingembodiment, the sub-module 650 may provide indications of which users inthe community 14 have worked together in the past. Such indications canbe shown as a social-network map that indicates the relationshipsbetween any two (2) users via a visual connection (e.g., a line or arc).In addition, the connection in the social-network map could indicate thefrequency in which the two users have worked together, such as byshowing a frequency calculation along the connection between two users.This could indicate a preference between certain users in the community14 to work together on projects, which may assist in the formation ofteams.

It will be appreciated that certain outputs generated by the taggingsub-module 650 may be used with other sub-modules, such as the searchsub-module 640. For example, a general architect may need to find alandscape architect for her upcoming commercial office building project.

Because this office building is intended to be a showcase project, shewants to select from the best landscape architects possible. To do this,the general architect uses the UI provided by the search sub-module 640to identify landscape architects within the user community 14 that arehighly rated and/or recommended by others. In certain case, she maysearch according to a general satisfaction rating (e.g., show thoselandscape architects with a general score of at least 4 out of 5), or incases where a user's work is rated according to several dimensions, shemay search based on a particular dimension (e.g., show those landscapearchitects whose work quality is rated at least 4 out of 5). By usingthe search sub-module 640 in this way, the general architect can quicklycreate a short-list of possible landscape architects for her showcaseproject.

Output(s) from the tagging sub-module 650 may also be used by the emailmanagement sub-module 620 to alert other users and collaborate work ingeneral. For example, assume that the system 10 is configured in such away that the completion of a task by a first user in a project (e.g., aworker or junior employee) must be satisfactorily rated by a second user(e.g., a supervisor or senior employee) before the task may beconsidered complete and/or ‘signed-off’. The tagging sub-module 650 maybe used by the second user to rate the work of the first user anddetermine whether the task is indeed complete and may be thereforeconsidered signed-off. When the tagging sub-module 650 indicates thatthe task has been signed-off by the second user, the email managementsub-module 620 may send a certain indication (e.g., an email, an updateto an RSS feed or a ‘tweet’) to other members of the project team that aparticular task has been completed and that any dependent tasks may nowcommence. In this way, the sub-modules 620 and 650 may be used toco-ordinate work between team members.

FIG. 7 shows the components of the building projects database 312 thatis generally used to store project-related information accessed by thebuilding projects module 302. The database 312 is comprised of a set ofprojects 710 ₁ to 710 _(N), as well as a set of project templates 750.

The set of projects 710 ₁ to 710 _(N) within the building projectsdatabase 312 includes all projects that have been added to thecollaboration system 10 by members of the user community 14. As aresult, the set of projects 710 ₁ to 710 _(N) includes completedprojects, ongoing projects that are not completed and future projects onwhich work has not yet begun.

In one specific example of implementation, a project may be conceptuallyviewed as a combination of activities (referred to here as events), aswell as a general group of people and specialized sub-groups of people(teams) that carry out these events. As a result, each project in theset of projects 710 ₁ to 710 _(N) include a project identifier 720, agroup of events 730 (also referred to as an ‘events group’) and a set ofteam parameters 740. Therefore, a project 710 _(i) would contain aproject identifier 720 _(i), an events group 730 _(i) and a set of teamparameters 740 _(i) that may be distinct from other projects in the setof projects 710 ₁ to 710 _(N).

The project identifier 720 allows the project to be uniquely identifiedwithin the building projects database 312, as well as be identified bypotential users who may become involved with the project. This allowsthe system 10, as well as its users, to find different projects withinthe building project database 312.

The project identifier 720 is typically a numeric or alphanumeric valuegenerated by the collaboration system 10 (and more specifically, theprojects module 302) at the time when the project is created in thebuilding projects database 312. For example, the module 302 may create agenerated unique ID string or GUID (e.g., GUID_(—)125S729fD546dF4587d15)to ensure that the project identifier 720 for newly created project willbe unique in the database 312.

The identifier 720 may also include an alphanumeric value that can bedefined by the user who creates the project. For example, a user mayassign a common name, such as:

-   -   a building's name (e.g., “High Holborne Mall”)    -   a building's address (e.g., “785 Bay Street”); and/or    -   a code word or phrase that represents a proxy for its name        (e.g., “Project Phoenix Ascendant.

In such cases, the project identifier 720 may be separate from thecommonly-known name of the project, or the commonly-known name may beincluded in the identifier 720. In the former case, the buildingprojects database 312 may provide a field or other placeholder thatassociates the project identifier 720 with its commonly-known name.

The events group 730 defines a set of events that are associated witheach project in the set of projects 710 ₁ to 710 _(N). As used here, thegeneric term “event” refers to an occurrence related to the project thathappens in time and has time values associated with it as a result.Depending on the current time, certain events in the event group 730_(i) may have already occurred, other events in the group may bepresently occurring, while yet other events in the same group may haveyet to occur in the future.

Events in the event group 730 _(i) typically also have an ‘action’component that defines a general goal or objective towards which theevent is aimed. For example, a particular event may aim to enable orencourage communications between one or more persons or groups on aparticular topic, either in a synchronous manner (i.e., an eventrelating to a meeting) or asynchronous manner (i.e., an email thread ordiscussion relating to a topic).

It may be noted that the action embodied by an event may be itselfdependent on one or more activities related to one or more other eventsthat have their own time periods and objectives. For example, the eventdescribed above to encourage communications between persons may dependon certain other events occurring, such as travel arrangements beingmade and met for a face-to-face meeting, or telephone or videoconferenceconnections being established in the case of a teleconference or videoconference.

The events group 730 may comprise several different types of events thatcan include, among others:

-   -   timelines: a timeline is an event that acts as a parent to at        least one other child event;    -   tasks: a task is an event with starting and ending times during        which the activity the task represents is expected to be started        and/or performed, and may be considered a child of the timeline        event;    -   milestones: a milestone is an event with an end time but no        start time, thus defining a point by which the activity the        milestone represents is expected to be completed;    -   To-dos: a To-Do is an event that temporarily has no specific        times associated to it that can be used to create freeform lists        of activities to be performed;    -   Messages: manipulation of a message, such as the creation,        sending, reading, editing or deleting a message is an event;        accordingly, a single message may have a number of events        associated with it; and/or    -   Documents (which may also be called document version events):        manipulation of a document such as creation, deletion or        modification of a document is an event. Accordingly, a document        may have a number of events associated with it. For example, the        circulation of a particularly important document may be        reflected as a task where users are required to initially accept        responsibility and then identify when the task is complete        (i.e., the document has been reviewed).

Although further details for these events will be provided below, it maybe seen from the above that the inclusion and completion of certainevents within a project are likely to cause a cascade of resultingactions. For example, the completion of a document event by one user maycause a messaging event to occur, which indicates to other users thatthe document related to the document event is ready for their perusal orreview. Additionally, the completion of a document event may close thetime window assigned for a task, milestone or To-do event related to thedocument event.

It will be appreciated that other project-management systems andapplications may also include events similar to those described abovefor the event group 730 _(i). However, the events in these systemstypically include either an action component or a time component, butnot both. For example, typical project management systems may provide adocumentation-related event that defines the time during which adocument should be created (i.e., an event time component). However, theevent does not provide for the storage, circulation and/or archiving ofthe document that is the subject of the event, which is provided throughthe system 10.

Similarly, content management systems typically provide events for thestoring, circulating and archiving of a document (i.e., an event actioncomponent). However, these systems do not provide a time window withinwhich these activities may be scheduled and/or monitored, which isprovided through the system 10.

It may be recalled that the events group 730 _(i) includes an explicitmessage event. However, it will be appreciated that other types ofevents may have communications related to them. For example, a documentevent may have communications related to the content, format andaudience for the document associated with the event.

In another non-limiting embodiment of the system 10, communicationsrelated to an event will be stored and associated with the event so thata user can view this information along with details for the event andits status. This allows a user to review related communications for theevent in order to understand why the event is in its current state.

For example, assume that a first user creates a task event representingthe development of an initial grant proposal for a social housingconstruction project. The first user may send a message to other projectparticipants in order to generate discussion related to the grantproposal. The resulting discussion may yield many useful ideas relatingto the grant proposal itself (e.g., what the proposal should include,how it should be formatted) and/or offers of help for writing, editingand presenting the proposal.

Because both the task event related to the grant proposal and thecommunication related to this event reside within the system 10, thecommunications described above can be associated with the grant proposaltask event. For example, the representation of the task event in thesystem 10 may have a ‘communications’ or ‘discussion’ control (i.e., abutton, tab or icon) that appears when communication related to theevent exists. When a user activates this control, a threaded view of allcommunication relating to the task is displayed, which can be grouped bythe user according to subject, author or the time at which thecommunications was added to the system 10.

Because all of this information is associated with the event, when thetime comes to write the grant proposal related to the task, the authorswill have a body of information and an ad-hoc team of expertise to drawupon.

By associating communications with an event, the context of thecommunications becomes immediately apparent to any user who views theevent. For example, by associating communications relating to the grantproposal with its associated task event, any user who views the eventcan infer the context surrounding the associated communication.

This approach may be compared with existing project-management and/orcontent management systems which are provided here as non-limitingexamples and typically do not have a means to associate event-relatedcommunications with an event. As a result, events are typically managedin a first application (e.g., a project-management application likeMicrosoft Project) while communications about the event is typicallymanaged in a second, separate application (e.g., an email applicationlike Microsoft Outlook). Because these two applications are separate,the receiver of an email message with a somewhat cryptic subject line of“How are we doing with the proposal?” must attempt to deduce or inferthe sender's intentions, especially in cases where some informationrelating to the communications is either omitted or is unclear to thereceiver. (e.g., in the case of multiple proposals, what particularproject that is being referred to by the sender)

According to an embodiment of the present invention, an email messagewith the subject line of “How are we doing with the proposal?” would beassociated by the system 10 with the grant proposal task event. In thiscase, the receiver need not try to infer what proposal the sender isreferring to as it will be obvious from its associated task. Knowingthis information may enhance the efficiency of the receiver inresponding to the communicated intentions of the sender.

Certain of the events listed above may also comprise one or moreso-called ‘sub-events’, which as used here, may refer to child eventsrelated to a parent event. For example, a task event that represents abroad activity may have task sub-events associated with it that describethe steps or processes involved in this activity.

For example, assume that a junior architect who is working on a projectis asked by the senior architect to prepare a presentation for theclient next week regarding some aspect of the project. To record herwork for this activity, the junior architect may create a task event(e.g., a “Prepare

Client Presentation” task) in the system 10 with a starting date (e.g.,the current date) and the ending date (i.e., the date of thepresentation). By creating this event, the junior architect may be ableto identify the impact of this event on other tasks for the same project(or other projects) that she may also be responsible for.

Further assume that in order to prepare the presentation represented bythe task event, the junior architect must perform certain relatedactivities beforehand, including (among others):

-   -   writing text for the presentation;    -   generating images of the design of the interior areas and        exterior façade from the architectural computer files for the        project;    -   integrating the text and images for the presentation into a        presentation file, such as a Microsoft™ PowerPoint™ file; and    -   reviewing the presentation with the senior architect before the        scheduled meeting with the client.

To remind herself to perform each of these activities, the juniorarchitect may create a set of sub-events for the presentation taskevent. In particular, she may create a To-do sub-event that isassociated with the presentation task event that contains the above listof activities. As the junior architect completes each related activity,she may remove it from the To-Do sub-event until this list is empty,which also indicates that the presentation is ready to be presented tothe client and the task may be deemed finished.

It will be appreciated that events and sub-events are typically visibleto everyone working on a project, unless the event is otherwiseexplicitly designated as private. For example, the aforementioned To-dosub-event generated by the junior architect would be visible to otherproject participants, such as the senior architect, so that they couldassess the status and/or workload of the junior architect.

The visibility of each person's tasks within the system 10 can helpbreak down informational ‘silos’ that otherwise obscure each user'sroles, tasks and workload from others working on the same project.Removing these silos may help improve the efficiency of the overallproject since certain participants (such as senior management) canidentify potential bottlenecks caused by a particular person's excessiveworkload assignments. For example, if the senior architect saw that theaforementioned To-do event was the 101^(st) event assigned to the juniorarchitect that needed to be completed within the next two (2) days, thesenior architect may decide to assign this event to someone else.

It should be appreciated that while events created by a user in thesystem are typically visible to everyone, events can also be madeprivate to only the user who created them, or to a group designated bythe event's originator. Such privacy may be advantageous in that itprovides the user with a certain degree of freedom and independence inhandling activities that are associated with an event.

For example, the visibility of the To-do sub-event created by the juniorarchitect in the previous example may be restricted only to her; itwould not be visible to the senior architect or to other members of theproject team. This allows the junior architect to return, revise, amendand reorganize the items in the To-do sub-event, as well as associateother types of sub-events (such as task sub-events) with the parentpresentation task as necessary.

In this case, the senior architect and the rest of the project team onlysee the parent “Prepare Client Presentation” in the system 10. When theparent task is marked as complete (which can be done independently fromits associated sub-events), the senior architect and/or project teamwill know that the junior architect's presentation is ready.

Further information regarding events will be provided below, but it isworth noting that each type of event within the events group 730 mayalso have a status associated with it. In one non-limiting embodiment,the status of an event may simply indicate whether it is completed ornot (e.g., tasks shown as either “Done” or “Not Done”). Alternatively,the status of an event may further indicate to what degree it iscomplete either numerically (e.g., 47%) or alphanumerically (e.g.,“Started”, “Ongoing” or “Almost Finished”).

In another non-limiting embodiment, the status of an event in the eventsgroup 730 may also indicate the reason(s) why an event is incomplete,such as its dependence on an earlier event or on a decision that has yetto be made. For example, a task representing the selection of an HVACsystem for an office building may be listed as incomplete because ashort-list of HVAC system candidates has not yet been compiled.

In addition to providing an indication as to the general status of anevent, in another non-limiting embodiment of the collaboration system10, users may be provided with the ability to receive notifications whencertain activities related to an event occur.

One example of such notifications involve the ability to ‘check-in’ (oradd) documents and to ‘check-out’ (or remove) documents that areassociated with a documentation event in the system 10. The term“document” is used here in a non-limiting sense of any container that iscapable of storing information. Therefore, a ‘document’ may refer to afile generated by a word-processor such as Microsoft Word (e.g.,correspondence, reports or memos); emails, SMS text messages or otherelectronic correspondence; pictures or other images (e.g., JPEG files orTIFs generated by an incoming fax); spreadsheets (e.g., Microsoft™Excel™ files); audio, video or three-dimensional (3D) files; and anyother type of information container that is provided in an electronicformat.

When a user views an event in the system 10 that has a documentassociated with it, he or she will be advised of the general status ofthis document (e.g., “not started”, “in progress” or “complete”), aswell as whether the document is checked-in or checked-out of the system.For example, a user viewing a document event associated with a statusreport may see a message similar to the following: “Currently checkedout by Elmo David; checked out on 21 Apr. 2011 at 16:45 GMT.”

Although a document may be currently checked out by another user, it canbe viewed and/or managed in particular ways. In one non-limitingembodiment, a user can view a read-only version of the document as itwas last checked into the system 10.

For example, assume that a document event is associated with a weeklystatus report for the construction of an office building that identifiespotential bottlenecks in the building's construction. Further assumethat the latest version of the status report is being generated and istherefore currently checked out. In addition, assume that the generalproject manager has returned from three weeks vacation and wants to seeif the bottlenecks identified in the report she last saw before leavingon vacation are still there. To do this, the project manager wouldaccess the document event for the latest status report and then view theversion of the status report as it was when it was last checked-in.Although this copy of the status report is obviously incomplete, it maybe enough to provide the project manager with information as to whetherthe bottlenecks before she left on vacation are still affecting theproject.

In addition, notification for a document event can be configured suchthat when a particular action related to the associated document occurs,the user (or other users) would be notified. For example, a user canconfigure a document event such that the event is “reserved” by a userwhen the associated document is next checked in. In this case, when theassociated document is checked-in and becomes available again, thesystem 10 sends a notification to indicate to this user that thedocument has been checked in and reserved for them.

The ability to configure notification upon a particular action relatedto an event may assist the users of the system 10 because they need notmanually check the status of the event to see whether or not aparticular action has occurred. In the previous example where a user isnotified that their ‘reserved’ document has been checked in, it will benoted that this user is relieved of: a) having to manually check on theevent's status in order to check it out once it becomes available, andb) locating and/or contacting the person who has checked-out thedocument so that the document can be re-checked in.

Another example of how user notification related to events may occur canbe seen when a document is ‘pushed’ by one user to another. In thisnon-limiting embodiment, a first user designates a second user as thetarget for a document associated with an event, which may be currentlychecked-in or checked-out. If the document associated with the event iscurrently checked-in, the document event is assigned to the designatedsecond user and the system 10 notifies this user of the new event.Otherwise, the document event is assigned to the designated second useronce its associated document is checked-in and notification related tothis action is provided to the second user at this point.

It will be appreciated that an event can be pushed to more than oneperson, either simultaneously or in a particular sequence or chain. Thesystem 10 can be configured to notify users when the document movesbetween each person in the chain in order that its progress can bemonitored.

For example, a document associated with an event can be ‘pushed’ to agroup of reviewers in sequence so that a first reviewer may review theassociated document, add his or her comments or edits, and then passalong the document to the second reviewer, and so on. Setting up such asequence ensures that a) the document is reviewed by each reviewer inthe group and b) the document is forwarded from one reviewer to the nextwithout any undue effort on the part of the first reviewer.

When the document moves from one reviewer to another, the system 10generates a notification to one or more reviewers along the chain. Forexample, when the document moves from the second to the third reviewer,the system 10 may notify the fourth reviewer so that this reviewer canprepare to review the document (e.g., reserve time in his or herschedule, make sure he or she is in communication with the system toreceive the document, and so on). Alternatively, each time the documentmoves from one reviewer to another, all the reviewers in the chain ofreviewers are notified, such that each reviewer is aware of the progressbeing made by the reviewers.

Although the prior examples regarding event notification have involveddocument events, it will be appreciated that such notification can beconfigured for any event, and is not restricted to document events.

Furthermore, initiation of a task event may be dependent on one or moreother events in a project. For example, a task involving the electricalwiring of the 7^(th) floor of an office building may be dependent on thefollowing three (3) events: a) a document event associated with apurchase order (P/O) for the various materials, such as electrical wire,junction boxes and switches; b) a messaging event that transmits the P/Oto a electrical materials supplier; and c) one or more messaging eventsacknowledging receipt by the supplier of the P/O and an indication as towhen these materials will be delivered to the site, which marks thepoint at which the electrical writing task may begin.

The user creating the task event may configure it such that thecompletion of each dependency triggers a notification to one or moreusers who may be directly or tangentially related to the task. Forexample, the completion of the document event (i.e., the check-in of thepurchase order) may trigger a notification to a user who handlesprocurement that he or she must send the completed P/O to the materialsupplier. Likewise, the messaging event that sends the P/O to thesupplier may trigger a notification to one or more users in theaccounting department that a new P/O has been filed with a particularsupplier and that they should be expecting an invoice for this P/O fromthe supplier. The messaging events acknowledging that the P/O has beenreceived and the electrical supply materials are being shipped to thejob site may trigger a notification to certain users who are doing theelectrical wiring (e.g., electricians and their apprentices) advisingthem that they will need to start working on the 7^(th) floor of thebuilding soon.

It will be appreciated that the use of notifications to indicate actionsrelated to an event may help those involved with the event to identifypotential issues or bottlenecks beforehand. For example, assume thatnotification has been sent to the electricians related to the wiring onthe 7^(th) floor, but that the status of the task event related to thewiring of the 5^(th) floor is marked as “in progress” and the status ofthe task event for wiring the 6^(th) floor is marked as “late”. As aresult, a user may deduce from these facts that while the task event forthe 7^(th) floor can be started, it is unlikely to remain on scheduleunless additional resources (i.e., electricians) are brought on-board toperform this task.

It is worth noting that particular events in the above non-limitingembodiment are related within a hierarchy, namely timelines, tasks andsub-tasks. When such promotions (or demotions) occur, certaincharacteristics of the event change but the specific information relatedto the event (such as its status) remains the same.

Examples of such event promotions and/or demotions, include:

-   -   promoting a task event to a timeline event, which may occur if        the original task was defined too broadly and further        delineation of its component parts are needed; and/or    -   demoting a timeline event to a task event, which may occur if        the original timeline was created to account a very specific        action for which tasks are, in fact, unnecessary.

For example, assume that a task event titled “Develop project budget” isincluded with a project for a shopping mall. It will be appreciated thatactivities related to developing a project budget (especially for acomplex development project such as this) may, in fact, be quite acomplex and/or protracted procedure and involve more than one person.

Because the activity associated with this event are too broad,protracted and/or complex, the “Develop project budget” task can bepromoted to a timeline event. This promotion allows a set of task eventsto be created that are associated with the timeline event and which mayinclude (among others):

-   -   task 1: determine a budget for the pre-design and design phases        of the project;

task 2: determine a budget for the construction phase of the project;

-   -   task 3: determine a yearly operating budget for the building        based on a 50-year estimated lifespan; and    -   task 4: review and combine the budgets created in the previous        three tasks to create the overall project budget.

In addition, the user who was originally responsible for the promoted“Develop Project Budget” timeline (and likely created the aboveassociated task events) may invite a person who has certain specializedknowledge to assume the responsibility for each different sub-event.

For example, assume that a commercial development project in the aboveexample is using a design-bid-build approach. In this case, thearchitect responsible for the project's design may be invited to do task1 (i.e., determine a budget for the pre-design and design phases), theproject's general contractor may be invited to do task 2 (i.e.,determine a budget for the construction phase) and an accountant may beinvited to do task 3 (i.e., determine an annual operating budget). Byassociating each task event with someone who is best suited to do thetask, the possibility that actual budget for the project may moreclosely resemble that estimated by these individuals can be enhanced.

Each project within the set of projects 710 ₁ to 710 _(N) has a teamassociated with it. As used here, the term “team” refers to a particulargroup of people (who are likely members of the user community 14) thatare involved with the particular project.

The team parameters 740 for a project may define one or more roles foreach member of the team. A ‘role’ generally refers to the descriptor forone or more project responsibilities and describes the set of functionsthat the person assigned the role will contribute towards the completionof the project. For example, in the context of a construction projectthe “landscape architect” role may be responsible for certain aspects ofa building project, including (among others):

-   -   identifying aspects of the area surrounding a building (such as        its slope) that may affect the drainage of water;    -   designing walkways, signage and lighting systems to ensure that        people can enter and exit a building safely and securely via        various modes of transportation;    -   selecting certain types of trees, plants and other vegetation        that reduce water consumption and contribute to sustainable        development; and/or    -   determining personnel and material requirements for landscape        maintenance, which in turn help determine costs associated with        the operation of the building.

Advantageously, the use of roles within the team parameters 740 allowthe responsibilities for events (and in particular tasks) within aproject to be assigned long before it is know who the particular userwithin the user community 14 will be. For example, and with reference toFIG. 4, assume that Company B 420 represents a group of landscapearchitects, and the user profiles 340 ₁₅, 340 ₁₈ and 340 ₄₄ representthree (3) of the landscape architects within this company. Furtherassume that the scope of a newly created project 710 _(j) indicates thata landscape architect will likely be required in the future.

To allow events for the landscape architect to be created in an eventgroup 730 _(j), a role for ‘landscape architect’ can be created in teamparameters 740 _(j). In this way, tasks related to the landscapearchitect can be assigned to this role in the event group 730 j, eventhough which of the three landscape architects (i.e., those representedby the user profiles 340 ₁₅, 340 ₁₈ and 340 ₄₄) will undertake theproject has not yet been determined.

In addition to roles, the team parameters 740 also allow theidentification of those users (via their user profile) to whom rolesand/or events have been assigned. For example, assume it is decided thatthe landscape architect role will be assigned to the architectrepresented by user profile 340 ₁₈. The team parameters 740 _(j) will beupdated to indicate that user profile 340 ₁₈ has been given landscapearchitect role and therefore is assigned responsibility for those eventsand tasks associated with this role.

The building projects database 312 can include a set of projecttemplates 750. Each template in the templates 750 represents a projectwhose event group 730 and set of team parameters 740 are pre-populatedbased on prior knowledge and/or experience. When a new project 710 _(a)is created based on a template 750, the new project's event group 730_(a) and set of team parameters 740 _(a) will contain the pre-populatedset of events and roles from the template.

Using templates, such as the templates 750, can save a user considerabletime and effort during project setup, especially if it is known thatcertain projects closely resemble each other in terms of their eventsand team parameters. Using the context of construction projects as anexample, assume that the construction of shopping malls with an area ofbetween 5,000 and 7,000 square feet that are built in the south-westernpart of the U.S. state of Arizona has been seen to include on average1,278 separate events and 128 different roles within the set of teamparameters. By using a template to set up a project for a new shoppingmall of this type, the user is relieved of having to create all of theseevents and roles. In addition, the user could be sure that certainevents and/or roles related to the new project were not inadvertentlyomitted due to oversight or ignorance of their importance.

In addition, the use of the template 750 may allow certain specializedknowledge or techniques to be implemented within a project that wouldnot have occurred otherwise. For example, assume that the group oflandscape architects from company B 420 has identified an improvedmethod for estimating rainwater runoff amounts for buildings withexterior asphalt parking lots so that this rainwater can be captured andreused for landscape irrigation. By implementing this method within atemplate, other landscape architects at the company B 420 (and possiblythose not employed by this company) can benefit from this improvedmethod in their projects.

It may be recalled that an event comprised within the event group 730represents an occurrence or an activity in time. FIG. 8 shows how theevents within the event group 730 can be generally classified asbelonging to one of three (3) project phases, namely:

-   -   design phase events 810;    -   building phase events 820; or    -   maintenance phase events 830.

In the context of construction projects, the design phase events 810comprise both pre-design and design-related events related to allaspects of the design of a building up to the point at which the groundis broken and construction begins. Such events may include, amongothers:

-   -   evaluating and selecting sites for the building or construction        project;    -   evaluating and selecting the design (and architectural firm(s))        for the building;    -   determining the type of process to be used in running the        project;    -   conducting an environmental assessment of the selected site;    -   identifying the financial outlay and general budget for the        construction project;    -   conducting a request for proposal (RFP) process to select one or        more contractors for the project;    -   determining whether the construction project will attempt to        achieve a particular certification, such as LEED (and if so at        what level);    -   drawing up and submitting plans to various bodies (such as        professional organizations, governmental bodies and/or        certification bodies) for review and approval; and/or    -   milestones for when the design phase ends and the construction        phase begins.

The construction phase events 820 in an event group 730 comprise eventsrelated to the construction of the building for which the project wascreated. Such events may include, among others:

-   -   site clearance, which may involve demolition, detoxification,        topsoil storage and/or the extraction of original vegetation;    -   normal activities associated with construction, such as the        excavation and construction of foundations, construction of the        building's exterior, plumbing- and electrical-related activities        and HVAC installation and testing, among others;    -   establishment of industrial recycling centers and implementation        of recycling services during construction;    -   reuse of original building materials, in the case where a        building is being substantially demolished and/or the façade is        being refurbished;    -   installation of sustainable development-related systems such as        grey water/wastewater recycling or renewable energy systems        (e.g., solar panels or wind turbines);    -   monitoring air and soil quality during construction activities;    -   restoration of topsoil and/or vegetation during landscaping;    -   submission of related documentation to the government and/or        certification bodies; and/or    -   milestones for the end of the construction phase ends, the        occupation of the building and the beginning of the maintenance        phase.

The maintenance phase events 830 in an event group 730 comprise eventsrelated to the general operation of the building over its expectedlifetime, which may be expressed in decades. Such events may include,among others:

-   -   regular preventative maintenance of building systems, such as        HVAC systems (e.g., air conditioning/heating) or plumbing        systems (e.g., wastewater and stormwater recycling), among        others;    -   expected replacement of building systems as they come to the end        of their useful lives;    -   expected regular refurbishment of interior spaces, such as the        refurbishment of public spaces or interior offices in an office        building;    -   regular regeneration of vegetation for a green roof, where        applicable;    -   collection and review of data related to energy efficiency of        the building; and/or    -   review of existing and planned sustainability initiatives in        order to maintain or improve the building's certification.

It is worth noting that the maintenance phase events 830 are likely toconstitute a large portion of the total events within the event group730 for a given project. Those skilled in the art will appreciate thatalthough the events comprising the design and construction phase events810 and 820 may be measured in years, the events comprising themaintenance phase events 830 are likely to be measured in decades.

Furthermore, it will be appreciated that the maintenance phase events830 allow regular maintenance for certain systems to be planned far(i.e., years or decades) in advance of their execution. By creatingthese tasks ahead of time, knowledge regarding the most effectivemethods for maintaining such systems can be transmitted between someonewith certain specialized knowledge about that system to someone in thefuture who will be charged with maintaining the efficiency of thatsystem.

For example, assume that during the design of an office building, acivil engineer chooses a particularly high-efficiency air-conditioningsystem in order to qualify the building for an environment certificationsuch as the LEED certification. However, in order to keep the selectedair-conditioning system operating at peak efficiency, the filters withinthe system must be cleaned out on a weekly basis, rather than on amonthly or bi-monthly basis as is the case with other air-conditioningsystems.

To ensure that this maintenance is performed on a weekly basis, theengineer sets up a recurring filter-cleaning event in the maintenancephase events 830 to ensure that the filters are cleaned on a weeklybasis. Otherwise, the technician responsible for cleaning out thesystem's filters may only perform this task on a monthly or bi-monthlybasis, as is the case with other systems he or she may be familiar with.In such a case, the prospective gains in energy efficiency would not berealized, which could put the future LEED certification of the buildingin jeopardy.

It may be recalled that events within the event group 730 are initiallyassigned to roles within the team parameters 740. Typically, such rolesare used as placeholders until members of the user community 14 can beassigned to fill them.

FIG. 12 shows a flowchart that explains the process by which a personmay join the user community 14 by establishing a user profile with thesystem 10. Once a person has joined the user community 14, he or she mayassigned to roles for a particular instance of the project 710 _(N)stored within the project database 312, which will be discussed shortlyin the context of FIG. 13.

At step 1210, the person who wishes to join the user community 14(defined here as a ‘prospective user’) accesses the system 10, and morespecifically the community management module 304, in order to create auser profile. For example, the prospective user may click a button orother user interface (UI) element provided by the system 10 to accessthe community management module 304. Alternatively, the prospective usermay follow a hyperlink included within an email sent by an existingmember of the user community 14 in order to access the module 304.

The module 304 displays a user interface (UI) that is configured togather information related to the prospective user, including:

-   -   first name and last name;    -   user profile password;    -   contact details (e.g., address, telephone number and email        address);    -   related skills and/or abilities of the user (e.g., whether the        prospective user is involved in architecture or construction        and/or whether they are familiar with reading blueprints);    -   professional affiliations of the user (e.g., whether the        prospective user is a member of a architectural society); and/or    -   privacy settings that define whether the prospective user would        want certain information exposed to other users in the community        14, such as their location.

It will be appreciated that a certain minimum amount of information maybe initially provided by the prospective user in order to create theiruser profile in the system 10. For example, the user may only need toenter their first name, last name and email address to create their userprofile.

Other user profile information may be added by the prospective user ashe or she participates in the user community 14 over time, such as othercontact details and/or professional affiliations.

In addition, the UI displayed by the community management module 304 mayalso prompt the prospective user to agree to certain terms andconditions of use for the system 10 before the user profile can becreated. Those skilled in the art will be familiar with such terms andconditions and therefore such details need not be discussed further.

At step 1220, the user-related information entered by the prospectiveuser is added as a new user profile to the user profile database 314.Once the user's profile has been added to the database 314, he or shecan be assigned events related to one or more projects in the projectdatabase 312.

During this step, the new user profile is assigned a unique ID within inthe user profile database 314 so that the user can be identified withinthe community. The generation of such a unique ID is believed to be wellknown within the art and therefore need not be explained here.

It will be appreciated that between the steps 1210 and 1220, thecommunity management module 304 may perform certain tasks to check andconfirm the identity of the prospective user. For example, the module304 may compare the entered information against the user profiledatabase 314 to ensure that the prospective user does not already haveanother user profile.

Once the user profile is created within the user profile database 314,the community management module 304 may then perform certain follow-uptasks to ensure that the entered information for the prospective user iscorrect, including:

-   -   sending a confirmation email to the provided email address(es)        (e.g., via an email server) to ensure that the provided        addresses work;    -   calling the provided phone number(s) (e.g., via an Interactive        Voice Response (IVR) system) to ensure that the provided phone        numbers are correct; and/or    -   require that the new user somehow reply to a confirmation email        or phone call, such as by following an embedded hyperlink (in        the case of email) or pressing certain buttons on their phone        (in the case of an IVR system).

Once a user has their user profile stored within the user profiledatabase 314, they can participate in one or more projects stored withinthe projects database 312. More specifically, a user may be invited toassume one or more roles on a project. Once the user agrees to assumethis role for the project, they are assigned task responsibilitiesassociated with this role and/or can create tasks for which they may beresponsible.

For example, the designated architect for a project may be invited toassume the role of “project architect”. Once the architect agrees tothis role (the process of which is described below), he or she may beassigned responsibility for certain events, such as generatingblueprints or creating a virtual fly-through of public spaces. Thearchitect may also create events for himself or herself in addition tothose that were assigned previously.

As indicated above, when a user agrees to assume a role on a project,they may be assigned certain events within an event group 730 _(N) for aparticular project 710 _(N). FIG. 13A shows a flowchart illustrating aprocess in which a project is created and an invitation to one or moreusers to assume responsibility for such events may occur.

At step 1310, a first user selects or defines the type of project to becreated. The first user makes his or her selection/definition via a userinterface (UI), examples of which appear at FIGS. 9, 10 and 11. The UIherein described in these figures may be accessible only once a user haslogged into (i.e., had his or her user name and password verified by)the system 10.

In particular, the first user may access a user interface sub-module 910that is shown in FIG. 9. This sub-module may interface, or otherwiseco-ordinate, with a projects management sub-module 920 that may be apart of the projects module 302. Alternatively, the UI sub-module 910may remain independent of the module 920 (and 302), and only interfacewith one of these modules when called by that module or sub-module.Regardless of the particular architecture of the sub-modules 910 and920, it will be appreciated that the UI sub-module 910 can process boththe display of interfaces (i.e., displaying them on a screen), as wellas any concomitant input resulting from the display of the UI, such as amouse click, input from a keyboard or the tap of a stylus and/or a swipeof one or more fingers on a touch-sensitive screen.

FIG. 10 lists a set of interfaces that can be displayed by the userinterface sub-module 910 to the logged-in user. As used here, the term“user interface” (or simply “interface”) generally refers to a graphicaluser interface that allows the user to input information to the system10, as well as receive information from the system 10. The userinterface (such as those displayed by the sub-module 910, among others)is typically comprised of user-manipulatable controls that enable theuser to input and/or receive this information. Examples of such controlsmay include buttons, text fields, checkboxes, drop-down menus, radiobuttons and/or hypertext links, among many others.

It will be appreciated that the user-manipulateable controls within auser interface for the system 10 may be manipulated by a user in avariety of ways, including via:

-   -   a pointing device, such as a mouse;    -   a keyboard, such as by pressing certain key sequences;    -   a finger or stylus applied to a touch-sensitive screen, such as        that of a smartphone or tablet computer; and/or    -   a voice command where the client 16 or computing device 100 is        configured for voice input.

It will be appreciated that the manipulation methods described abovecomprise a non-exhaustive list as other methods exist and would fallwithin the scope of the present invention.

In particular, the sub-module 910 can display interfaces, such as:

-   -   a project-type selection interface 1010, which would typically        be used to select a type of project at the time of its creation;    -   a roles selection interface 1020, which would typically be used        to select roles for events within the events group 730;    -   a team member(s) interface 1030, which would typically be used        to assign an event to a particular team member included in the        team parameters 730;    -   a project template loading interface 1040, which would typically        be used to load a template for a project (and/or some part        thereof); and/or    -   a project management interface 1050, which would typically be        used to view and manage the project as it develops in real-time.

Returning now to step 1310, the first user would access the project typeselection interface 1010 via the UI sub-module 920 and then select oneor more type(s) of project from those listed in this UI.

In one non-limiting embodiment, the project type selection interface1010 may list a variety of project types, including:

-   -   the intended type of development (e.g., residential, commercial        or industrial);    -   whether the project is for a new development (e.g., a project        for a new housing development) or for a retrofit/update of an        existing development (e.g., a project to improve the energy        efficiency of an existing office building);    -   the certification level the project is expected to achieve, if        necessary (e.g., whether the project is expected to meet LEED        certification, and if so, what level of certification); and/or    -   the intended design process for the project (e.g.,        design-bid-build process or an integrated design process).

It will be appreciated that the above list is non-exhaustive as otherproject types may exist that fall within the scope of the presentinvention.

Alternatively, the selection interface 1010 may use techniques otherthan a list to allow the first user to define or select the projecttype. For example, the interface 1010 could identify certain projectcriteria by “interviewing” the first user by asking him or herproject-related questions, including:

-   -   what is the general type of building (e.g., residential,        commercial or industrial) that the project will represent;    -   what is the expected duration of the building's design and        construction;    -   whether achieving a particular certification (or level of        certification) is a design consideration for the project;    -   what type of design process is planned for the project (e.g.,        integrated design process, design-build process,        design-tender-build process); and/or    -   what is the expected lifespan of the building that the project        represents.

Based on the first user's responses to these questions (among others),the project type selection interface may be able to make suggestions orrecommendations as to the best type(s) of project for what the firstuser seems to be indicating. For example, a project for a residentialdevelopment with an expected 10- to 15-year lifespan would likelyrequire different project parameters than a project for a commercialoffice tower with a 60- to 75-year lifespan.

At step 1320, one or more instances of the project template 750 areloaded for the project type selected by the first user in the previousstep. It may be recalled that each template in the project templates 750represents a project whose event group 730 and set of team parameters740 are pre-populated based on prior knowledge and/or experience.

Based on this definition, it may be possible that one or more templatesfrom the project templates 750 may be associated with a particularproject type. For example, assume that the first user selects a projecttype for the construction of a 30 to 45 story commercial office towerwithin the downtown area of a major U.S. city from the project typeselection interface 1010. Further assume that the office tower projectis intended to achieve a particular level of LEED certification (e.g.,silver).

Once this selection has been made, the system 10, and in particular theprojects module 302 may identify one or more templates from the projecttemplates 750 that correspond to the project's criteria. For example,the criteria that the building must achieve a particular level of LEEDcertification may result in the selection of a project template thatcontains LEED-related events and roles in for the project's event group730 and team parameters 740.

It will be appreciated that certain templates comprised within theproject templates 750 may provide events and team parameters (i.e.,roles) for a complete project, while other templates contain eventsand/or roles for a portion of a project. For example, the events androles related to achieving LEED certification mentioned in the aboveexample may be contained in a separate template from those used to buildprojects. In such cases, when the first user indicates that the projectfor the office building requires LEED certification, the events androles from the LEED certification template may be applied once thedefault project has been created.

By allowing templates within the project templates 750 to contain aportion of events and roles in the overall events group 730 and/or teamparameters 740, it is possible to create a project dynamically bycombining a number of different specialized project templates. Suchspecialized project templates within the templates 750 may representdifferent approaches that could be taken to a particular project and/ordifferent aspects therein.

For example, assume that the first user intends to create a project inthe system 10 representing a new academic library that is to be builtusing an integrated design process (IDP). Further assume that theproject templates 750 includes a template that contains events and teamparameters for IDP construction projects, as well as a template thatcontains events for applicable to construction of a library.

For example, the template for IDP construction projects may compriseteam parameters that provide for the primary stakeholders including thearchitect, the building owner/operator and the main contractor(s). Thetemplate for library construction may include such events as:

-   -   a set of events during the design phase events 810 to ensure        that the foundations are reinforced for the substantial weight        of books to be housed in the library;    -   a set of events during the construction phase events 820 to        ensure that the spacing of book stacks is sufficient to allow        passage of book trucks, as well as wheelchairs; and    -   a set of events during the maintenance phase events 830 to        ensure that air filters within the library are cleaned out        regularly so that the number of airborne parasites (e.g., mites)        that feed on and destroy books are reduced.

When the project for the academic library is created in the buildingprojects database 312, the team parameters from the IDP template and theevents from the library-specific template within the project templates750 may be combined to generate the event group 730 and/or teamparameters 740 for the particular project. In this way, the specializedinformation and knowledge that is contained in each template may becombined to ensure that a project can benefit from the application ofsuch knowledge.

It will be appreciated that the above example showed how two (2)templates from the project templates 750 could be combined during thecreation of a project. The number of templates used in this example wasprovided for the sake of simplicity and projects could be generated bycombining two (2), three (3) or more templates from the projecttemplates 750.

It will also be appreciated that the event group 730 created as a resultof a combination of one or more templates from the project templates 750may still be modified by the first user (and/or by subsequent users) sothat the resulting events in the event group 730 accurately reflects theexpected events in the various project phases, such as the design phaseevents 810. In this way, the users retain ultimate control over theevents in the events group 730 so that these events can be modified toadjust for prior experience and/or changing circumstances.

In a non-limiting embodiment, one or more of the templates within theproject templates 750 may be selected automatically by the system 10based on the first user's responses to questions posed to him or her viathe project type selection interface 1010. In this way, the user wouldnot need to know the various templates within the project templates 750in order to use them within his or her projects.

For example, assume that the interface 1010 included a question relatingto the construction management approach for the new project, such as:“What type of construction project management approach do you intend touse?

-   -   a) Design-Bid-Build/Design-Tender-Build    -   b) Design-Build    -   c) Integrated Design Process (IDP)

Depending on the first user's response to the above question, thetemplate for the appropriate management approach can be selected fromthe project templates 750. Furthermore, if the project templates 750contain many such templates to choose from, the system 10 can shieldfirst user from being overwhelmed, confused and/or making aninappropriate choice of template.

In an alternative embodiment, the first user may be provided with a UIthat would allow him or her to select templates from the projecttemplates 750 directly. For example, the project type selectioninterface 1010 could provide a user with a template UI that would listall of the templates within the project templates 750, such as in acollapsible list organized according to type of project, among others.Alternatively, the template UI may provide certain controls (e.g.,drop-down lists) to allow the user to identify certain criteria that aprospective template must meet in order to be considered. Criteria thatcould be represented in such a way include (among others):

-   -   project type (e.g., residential development vs. industrial        development);    -   project deliverable (e.g., office building, residential home,        factory or library);    -   expected operating lifespan of the deliverable (e.g., 5-15        years, 10-30 years or 50-75 years);    -   general project approach (e.g., design-bid-build vs. integrated        design process); and/or    -   certification level (e.g., silver LEED certification).

It may also be possible that the first user (and/or other users withinthe user community 14) can be provided with the ability to contributeand share templates within the project templates 750 with other users ofthe system 10. This ability may be provided by allowing members of thecommunity 14 to apply and/or modify certain restrictions relating totheir templates' privacy. In these cases, removing such restrictionsfrom (or conversely, by enabling the ability to share) one or more oftheir project templates, the entire community 14 may be provided withaccess to such templates.

Advantageously, the ability to contribute and share templates mayenhance the transfer and sharing of knowledge within the user community14. For example, assume that a user in the community 14 has knowledgeabout the operation of a certain type of high-efficiency commercialboiler, and in particular, detailed knowledge of when the heatingelements of the boiler need to be changed beyond that available in thedocumentation and/or training provided by the boiler's manufacturer.Furthermore, assume that this user created a series of maintenance phaseevents 830 for a particular project that used this boiler within aproject template that was found to be particularly helpful.

If this user has the permission to contribute their boiler-relatedtemplate to the user community 14, he or she could share it by removingany privacy restrictions placed upon it. In this way, other users in thecommunity 14 who are using the same boiler in their projects couldadjust their maintenance phase events for this component based on theknowledge contained in the user-contributed template.

In the above described embodiment, a template within the projecttemplates 750 was contributed to and shared freely within the usercommunity 14. Alternatively, user-contributed templates in the projecttemplates 750 may also be offered for sale by their creator(s). In thisalternative embodiment, a user within the community 14 may create atemplate within his or her project templates and then offer it for saleto other users. Users who wish to purchase this template could contactthe seller (e.g., via the messaging features in the system 10) andarrange for payment, which may be handled internally within the system10 itself (e.g., via a shopping cart mechanism) or by an externalprovider (e.g., via PayPal™). Once the transaction is complete (i.e.,the payment has been made to the seller of the template), the system 10could make the project template available to the buyer immediately.

Those skilled in the art will appreciate that a marketplace for projecttemplates could be developed within the system 10 under such anembodiment. Furthermore, such a development could inspire users in theuser community 14 to continue to develop and refine their templatesafter their initial development so that other users would continuebuying them long after the original project for which they weredeveloped was completed.

In the aforementioned alternative embodiment(s), a template within theproject templates 750 is either freely offered or sold to the usercommunity 14 by an individual member of this community. However, it isconceivable that a template within the project templates 750 could alsobe offered freely and/or provided for sale by a named group within thecommunity 14, such as by an equipment manufacturer.

In such a case, the template within the project templates 750 that isprovided or sold through the marketplace may contain events (such astasks and/or document events) that relate to the installation, operationand/or maintenance of one or more models of equipment provided by thenamed group. For example, the manufacturer of the aforementionedhigh-efficiency boiler could produce a template within the projecttemplates 750 that comprised tasks in a maintenance schedule needed tokeep the boiler working at a high efficiency. This template could beprovided freely by the manufacturer to the user community 14 to generategoodwill towards its products and/or to reduce support costs associatedwith the particular piece of equipment. Alternatively, the templatecould be sold by the equipment manufacturer through the marketplace inorder to generate additional post-sale income for the manufacturer.

Alternatively, the marketplace for project templates may developpartially outside of the system 10. More specifically, a marketplace forproject templates 750 may be developed in project templates betweensuppliers of equipment typically included in a project and thepurchasers (or renters or leasers) of such equipment.

In this alternative embodiment, the purchase or lease of a certain pieceof equipment from a first party (e.g., an equipment manufacturingcompany or maintenance company) by a second party (e.g., a contractor orbuilding owner) for a project may include the provision of one or moreproject templates for that piece of equipment. For example, assume thata project in the project database 312 for a commercial shopping malldevelopment requires the purchase of several large-scaleheating/air-conditioning units. These units typically have certainpre-defined maintenance periods, such as during the spring (or fall)when a unit is typically switched from heating air to cooling air (orvice-versa).

During the negotiations to purchase such units with the contractor orbuilding owner, the HVAC equipment manufacturer may offer to provide oneor more project templates for these units that include predefined eventscovering the installation, testing and maintenance of these units overtheir expected operational life. For example, the project templateprovided by the manufacturer could include:

-   -   document events relating to the integration of the        heating/air-conditioning units during the design phase events        810;    -   timeline, task, milestone, to-do and document events relating to        the installation and testing of the heating/air-conditioning        units during the construction phase events 820; and/or    -   timeline, task and document events relating to the maintenance        of the heating/air conditioning units during the maintenance        phase events 830.

Should the contractor or building owner agree to the sale, themanufacturer (who likely has a presence in the user community 14 as anamed group) can immediately make available the project templates forthe models of heating/air-conditioning units sold to the contractor orbuilding owner. The contractor or building owner can then import thesetemplates to his or her project in order to add theheating/air-conditioning unit-related events to the project, withouthaving requested or paid for the sale via the system 10.

Bundling one or more equipment-related templates within the projecttemplates 750 with the purchase of the associated piece of equipment mayprovide certain benefits, including:

-   -   differentiating the equipment manufacturer from other        manufacturers of similar equipment, making his or her products        more attractive to prospective clients;    -   ensuring that the contractor, building owner (or building        maintenance company) is in possession of a comprehensive set of        documentation for the equipment in advance of the hand-over        date;    -   ensuring that the maintenance tasks associated with a piece of        equipment are established according to the manufacturer's        recommended schedule, which may decrease the number of support        calls/visits needed to maintain the equipment;    -   providing a method by which the equipment manufacturer can gauge        the need for replacement parts or supplies, as the maintenance        schedule for the equipment is known to the manufacturer and may        be monitored and compared to those of other projects using the        same equipment; and/or    -   in the case where the equipment is subject to a recall notice,        allowing the manufacturer to more effectively schedule the        delivery of replacement parts and/or the activities of staff to        install these parts in the equipment.

It will be further appreciated that the templates provided by equipmentmanufacturers in this way may be identical to those already on sale inthe system 10 or may be customized to the specifications and/or locationof the project. For example, if the shopping mall in the previousexample is located particularly far north (or south) of the equator(i.e., near or within 60° latitude N or S), the manufacturer may adjustthe timing of certain events and tasks in the maintenance phase events830 to account for the relatively longer winter period.

The above alternative embodiments have described possible scenariosinvolving the provision of templates by different means (e.g., viapurchase from an individual or company, as well as bundled with aparticular piece of equipment). However, it may also be possible thatthe system 10 could provide the ability for a user to choose fromvarious versions of the same template that differ in terms of theircomprehensiveness and/or level of support. As a result, a user couldselect a version of a template that best suits his or her needs and/orbudget.

For example, assume that a world-renowned energy efficiency expert forlarge office buildings has created a system that can help improve theenergy efficiency in other office building projects. Although the system10 may provide a basic energy-efficiency template, the expert hasdecided to offer the following three (3) versions of a template thatimplements his system:

-   -   a) a paid ‘professional’ template version that provides a        comprehensive implementation of the expert's energy-efficiency        system, but does not come with any support from the expert;    -   b) a paid ‘professional expert’ template version that costs more        than the ‘professional’ version and contains the same version of        the energy-efficiency system as in the ‘professional’ version        but provides for a project team member to be trained by the        expert to act as a guide or facilitator and includes a certain        amount of support provided by the expert to the        guide/facilitator; and    -   c) a paid ‘enterprise expert’ template version that costs more        than the ‘professional expert’ version but includes the expert        joining the team in order to consult directly at a certain phase        of the project, as well as providing considerably more support        from the expert.

Depending on how the efficiency expert chooses to price the aboveversions of his template, a prospective user could choose the version ofthis template that best suits their needs. For example, if the userknows that providing better energy efficiency is going to be a majorfactor in the overall success of his or her office building, he or shemight choose the ‘professional expert’ or ‘enterprise expert’ versionsin order to take full advantage of the leading expert in this field. Onthe other hand, if the user cannot afford the cost of these versions, heor she may choose to go with the ‘professional’ version in order torealize at least some of the improved energy efficiencies in theirproject.

In the above example, the main price differentiator between the includedversion of a template and the expert's various template versions was a)the implementation of the expert's system in the project and b) thelevel of support provided by the expert to users of the template. It isconceivable that templates could be differentiated based on otherfactors, such as the number and type of roles or events in a project(e.g., an expert template provides certain roles not included in thebasic template), the sequence of events in a project (i.e., events beingsequenced in a particular way to realize certain efficiencies) and/orhelp content relating to events and roles, among others.

It may be recalled that the system 10 can be used as a marketplace thatfacilitates both the storage of templates (and/or template versions), aswell as their discovery and purchase by users. This allows the seller ofa template to realize some remuneration for their time and effort increating the template. In addition, the system 10 may charge a fee(which may be a flat fee or a percentage of the transaction amount) tothe buyer and/or seller for each purchase made. In this way, the cost ofproviding a fully-featured marketplace can be subsidized and/orrecovered from the system's 10 users.

Although the use of templates within the system 10 is intended to assistand simplify the act of creating events and managing projects, it islikely that users (and in particular, new users) will require someassistance as they learn how to use the system 10. In order to providesuch assistance, another non-limiting embodiment of the system 10includes a help system that provides integrated, on-demand help inresponse to a user request (i.e., by clicking a help button or icon,clicking of a particular tab or use of a particular key such as F1).

The integrated help system may provide access to help content that canoriginate from different sources and may have very different objectives.For example, the system 10 itself may provide its own help content thataims to help users navigate the UI, identify different UI elements andlearn the basic workflow involved with setting up projects and workingwith events. In addition, each template with which a user interacts mayprovide its own help content that aims to assist the user with theparticular workflow and events included with the template.

For example, assume that a new user has joined the system 10 and hasaccepted a role working on a project to expand a university dormitorybuilding. This project uses several templates, including anenergy-efficiency template, a LEED certification template, and an IDPtemplate used for general construction management. Further assume thatthe system 10 provides generic help content related to the UI and thateach template provides its own help content that is specific to itstemplate (e.g., the IDP template provides help content related toconstruction projects managed via the IDP approach).

Because the user is new, he or she needs assistance in navigating the UIof the system 10 (which is described below), and so activates theintegrated help system via a control (e.g., button, icon or keystroke)to get information related to the purpose and usage of a particular UIelement. In this case, the help system retrieves the relevant contentfrom the generic help system for the system 10 and displays it to theuser.

With this information in mind, the user then turns his or her attentionto a particular event in the energy-efficiency template associated withthe project. Since the user is not familiar with the way the template isset up and how this particular event falls into the general workflow,the user again consults the integrated help system. In this case,however, the help system retrieves the relevant content from the helpcontent associated with the template rather than that for the system 10.

Those skilled in the art will appreciate that the system 10 may displayhelp content in various ways, including within a web page (so-called“HTML Help”), in a pop-up window, through tips added to the UI or byplaying a video or audio file, among other possibilities. The user mayalso indicate to the system 10 in what format he or she would like toview help content, which allows the system 10 to deliver help content ina manner which is more effectively retained by the user.

Therefore, it will be understood that no matter how many help contentsources are available to a user, the integrated help system provides asingle point of access to all of them within the system 10. As a result,the user does not need to be aware of the origin of the particular helpcontent, as the help system handles the retrieval and display of thecontent to the user.

In another non-limiting embodiment, the integrated help system mayprovide an expert locator system to help a user access both help content(as described above), as well as to locate and contact one or moreexternal experts who can assist the user should they need further help.For example, assume that the user described above who is working on anenergy-efficiency template has reviewed the help content related to aparticular event in the template, but still does not understand how thisevent fits into their project. If the user has access to the expertlocator system (which may be provided upon payment of an additional feeor as a licensing option separate from the template itself), he or shecould use the integrated help system to contact an expert to answertheir question regarding the template. Such contact may be asynchronous(e.g., via an email message) between the user and the expert orsynchronous (e.g., a VoIP call) between these two parties.

In the expert locator system described above, the user requiringassistance may locate and contact an external expert. However, it isalso possible that the expert locator system may allow the user tosearch the existing user community 14, and more specifically, the userprofile database 314 to locate the desired expertise. This approach mayhelp to connect a user who is seeking assistance more quickly with auser within the user community 14 who is available to provide thatassistance.

It should be appreciated that although the expert presented in theexample of the expert locator system described above is human, thisshould not be seen as an absolute requirement. In an alternateembodiment, the “expert” provided by the system may in fact be asoftware agent that utilizes knowledge based on aggregated usage datagenerated by the users of the system 10 in order to provide assistance.In this case, the software “expert” may have identified that many priorusers of the same energy-efficiency template were confused by thisparticular event and that a particular workaround helped them overcometheir confusion. In this case, the “expert” would suggest implementingthe workaround to the user via the integrated help system. A method bywhich a software agent can generate knowledge based on user interactionwith the system 10 will be presented later.

The result of the prior steps 1310 and 1320 is the creation of a newproject 710 _(i) within the projects database 312, including thegeneration of an events group 730 _(i) and a set of team parameters 740,for the project 710 _(i).

At step 1330, roles for the events within the events group 730 may beselected based on the type of event and/or prior experience, among otherfactors. During this step, therefore, each event within the events group730 _(i) is provided with a role to indicate the person(s) who will beresponsible for executing the activities associated with the event.

Certain types of events may include default roles for the team member(s)expected to complete those events. These default roles for events may bederived from a set of default roles that is maintained for all projectswithin the projects database 312 and assigned by the projects module302. For example, events related to maintenance of an air conditioningsystem within the maintenance phase events 830 for the project 710 _(i)may indicate a role for an “HVAC Technician” or “Air ConditioningMaintenance Engineer”, among other generic terms that could be used forsuch a role.

It will be appreciated that the association made between a particularevent in the events group 730 and its default role from the set ofdefault roles by the projects module 302 may be based on known historyor prior experience. For example, certain events in the design phaseevents 810 (e.g., responsibility for the building's overall externalaesthetic design) are typically associated with an architect. As aresult, such events would typically be associated with the default“architect” role by the module 302.

Alternatively, certain events in the events group 730 may be associatedwith roles based on prior history or experience. For example, assumethat events within the design phase events 810 that relate to thecreation of the physical or virtual model of a building are assigned bydefault to the role of “architect”. However, assume that for pastprojects, these events were actually assigned to and/or completed by aperson with the role of “architectural model maker” who was employed bythe architect. Therefore, it is similar events for current and/or futureprojects should likely be assigned to the “model maker” rather than tothe “architect” role.

There are several ways that such role reassignment could take place. Inone non-limiting embodiment, a user could manually request that theprojects module 302 reassign such roles by extracting them from pastprojects created by and/or worked on by the current user. In thissituation, the modeling events in the design phase events 810 would beinitially assigned by the module 302 to the architect role. When theuser requests role reassignment to take place (which may includeidentifying the project from which the module 302 should use as a basefor such reassignment), the modeling events would then be reassigned tothe ‘model maker’ role.

In an alternative embodiment, the projects module 302 might learn suchrole reassignments by extrapolating from an analysis of past projects.For example, certain logic built into the module 302 may review projectroles reassigned for each completed project for a particular user. Suchlogic may determine that in each project, the modeling events within thedesign phase events 810 were assigned to a ‘model maker’ role. Based onsuch history, the module 302 may extrapolate that for future projectscreated by the same user, such events should be automatically assignedto a default ‘model maker’ role.

During this step, a list of all of the default roles assigned to theevents group 730 for the project may also be compiled for a user'sreview. The compilation of this list may allow a user to identify and/ormanually reassign roles for certain events, such as the reassignment ofphysical or virtual modeling events in the design phase events 810 from“architect” to “model maker” roles described above.

It may also be possible for the first user to create new roles forcertain events in the events group 730 during this step. For example, ifthe “model maker” role was not part of the default set of roles includedin the projects database 312, the user could add it manually and thenreassign roles for events to this new role.

The user may be provided with the ability to add new roles (and/ormanage existing roles) via the roles selection interface 1020 describedearlier. For example, the interface 1020 may include an “Add New Role”control (e.g., clickable button or link) that would display a userinterface that would allow a user to define a new role for the project.Criteria that could be defined via such a UI may include (among others):

-   -   name for the new role (e.g., model maker, architectural modeler,        virtual modeler);    -   a brief description of the new role (e.g., “This role was        created by Bob to define events outsourced to Janie at        Models-R-Us”;    -   certain criteria that must be met by those assigned to the role,        such as educational criteria (e.g., possess a Bachelor of        Engineering), professional criteria (e.g., be certified as a        LEED AP), professional experience (e.g., have at least 10 years        experience in office building design) and/or other criteria that        could be quantifiably measured, such as insurance coverage        and/or number of employees.

Once a new role is created, it appears in the compiled list of roles.Typically, role reassignment occurs during the development of theproject team, and more specifically, by the acceptance of responsibilityfor an event by a user whose role is different from the role originallyassociated to the event. While this process will be described below, itis worth noting that role reassignment may also be performed during thisstep to ensure that all of events in the new project (as displayed inthe compiled list) are covered adequately by a default role.

At step 1340, the project team is assembled from users in the usercommunity 14. The process by which the project team is assembled will bedescribed in more detail below, but in brief, the first user invitespeople (who may be within the user community 14 or people who arecurrently outside of the collaboration system 10 entirely) toparticipate in the project by taking responsibility for a role and itscommensurate tasks. The system 10 monitors the acceptance of theinvitations until all roles on the project team are filled and theproject team is considered assembled.

While further details of the above process will be described shortly, itmay be appreciated that the approach towards assembling the project teamis unlike those commonly found in similar systems. In particular,prospective members of a project team are invited to join the projectand take responsibility for a role, rather than simply being assignedtasks as a so-called “resource” residing within a spreadsheet or Ganttchart.

By approaching the assembly of a project team as a community-buildingexercise (e.g., through invitations and role-related responsibility),the collaboration system 10 may help develop more open communicationsbetween project team members than might otherwise occur. Advantageously,such open communication within the project-related community may servehelp to solve problems more efficiently as they arise.

The result of step 1340 is the assemblage of the project team. In thecase where a project team member has a user profile within the userprofile database 314, the acceptance of the invitation may cause severalactions to occur, including:

-   -   updating the member's user profile 340 _(i) (and more        specifically, the list of active building projects 520) to        indicate that he or she is now participating in the project;    -   updating the project team parameters 740 i to indicate that the        user has accepted responsibility for the indicated role; and    -   updating the events in the event group 730 i related to the        accepted role to indicate the user now responsible for those        tasks.

In the case where a project team member is not a member of the usercommunity 14, their acceptance of a role within the project typicallyresults in the member joining the user community 14 and creating a userprofile 340 _(i) within the user profile database 312. This process wasdescribed previously with respect to FIG. 12 and so need not beexplained here. Once the team member has obtained a user profile 340_(i), however, his or her profile is updated in a similar manner to thatdescribed above.

At step 1350, the permissions for certain project team members may beadjusted where necessary. This step is optional and may occur when arole in the project is changed and/or the original first user fulfillingthat role is replaced by a new second user.

Typically, permissions within a project are assigned to roles ratherthan to individual users in order to simplify the security model andallow turnover in the project. For example, assigning a default set ofpermissions (e.g., read, write, create, update, administer, execute anddelete, among others) to a generic “architect” role allows anyone whoassumes this role to also inherit those permissions assigned to therole. Therefore, should Bob Smith (the user originally assigned to the“architect” role) turn over responsibility for this role to Jane Brown(another architect and user in the system 10), Bob does not have toensure that Jane has the same set of permission that he does before thistransfer of role title (and commensurate event responsibilities) takesplace. Advantageously, this approach simplifies the transfer of rolesbetween users while continuing to ensure that the permission setrestricts what any particular user can do.

In some cases, however, the assigned role does not carry with it all ofthe needed permissions. For example, assume that team parameters 740_(j) for a project 710 _(j) contains an “HVAC trainer” role to indicatethe person that will train other users in the operation and maintenanceof the HVAC system. Further assume that this role is assigned readpermission by default, as it is not expected that the trainer will needto access more than the documentation already stored in an event group730 _(j) (i.e., the documentation tasks within this group).

However, assume that the user who assumes the trainer role realizes hisor her tasks include an event for “Developing training videos” and/or“Distribute training documentation for review”.

Because these permissions entail a wider set of permissions than iscurrently assigned, the permissions for the trainer are adjusted at thisstep to include write, create, update and delete permissions as well.

It will be appreciated that once a first user has acceptedresponsibility for a role in a project, any change to his or herpermission set changes the permissions for both the role and user. Thisis because the user and his or her role are considered identical onceresponsibility has been assumed. Should the first user be replaced by asecond user (i.e., the original person shifts the responsibility for therole to another), the second user will inherit the same set ofpermissions, while the first user will lose his or her original set ofpermissions.

At step 1360, information regarding the new project and its assembledproject team are stored in the projects database 312. It will beappreciated that this step, and more generally the entire processdescribed above, occurs within the context of changes made to theprojects module 302, the project database 312, as well as the userprofile database 314 (which is likely accessed via the communitymanagement module 304).

Those skilled in the art will realize that although this step statesthat a project is stored within the databases 312 and 314 at this point,this action is likely occurring continuously during all of the steps inthe process outlined above. Therefore, the “storage” action indicated instep 1360 may include:

-   -   a so-called “final commit” action made to the databases 312        and/or 314 that updates their tables on a more-or-less permanent        basis; and/or    -   the generation of a backup of the new project file and its        associated information within the collaboration system 10, such        that this information may be recalled or reconstituted in case        of database corruption or failure.

The creation of a project, its events and their associated roles asdescribed above has been described as being based on a template withinthe project templates 750 that is associated with the project type(s)selected at step 1310. For example, assume the first user selected thefollowing project types at step 1310:

-   -   commercial development of a urban medical professional center;    -   IDP process is to be used to facilitate the design and        construction of the development; and    -   an objective of the project is to achieve and maintain LEED        certification at a particular level (e.g., LEED NC Silver).

As the process has been described above, the project module 302 wouldlikely choose and/or combine one or more templates from the projecttemplates 750 corresponding to each of the project types identifiedabove in order to develop the events and roles for this project.

It is conceivable, however, that the first user may not want to start aproject with a set of events and/or roles from a predefined projecttemplate. Instead, the user may wish to start with a project that iscompletely empty of events and/or roles so that he or she could buildthese up himself or herself.

For example, this user may be interested in building a templatecontaining the maintenance phase events 830 for a particular piece ofequipment, such as a wastewater or stormwater run-off treatment unit. Inthis case, the user may not need or want to have any events and/or rolesgenerated since these may not exist and/or the project templates 750 mayonly include this unit as a component of much larger projects forcommercial or industrial property development(s).

To provide the first user with the ability to build such a project, theproject templates 750 may include a blank project template that isdevoid of predefined or preconfigured events and/or roles beyond thoseneeded to establish the project within the project database 312. Whenthis blank template is applied to a project, the user becomesresponsible for entering events and developing roles in the processdefined in FIG. 13B, rather than adjusting or customizing thesepre-defined events and/or roles. In this way, a user can create aproject (or project template) from scratch, without having any presetrestrictions and/or preconceived notions about what events and/or rolesare necessary.

In the above embodiment, a user is likely to use the controls within thesystem 10 to manually populate the blank project template with eventsand roles. However, in certain circumstances, the user may already havea file similar to the project template he or she wishes to create. Forexample, the user may have a file that was created in Microsoft® Excel®,Microsoft® Project or Google™ docs that contains a list of events and/orroles for the project, or portion thereof. Although the user couldre-enter information from these files manually to the system 10, itwould obviously be preferable that the user could ‘import’ (i.e.,transfer) these events and roles to the blank template.

In a non-limiting embodiment, the system 10 (and more specifically, theprojects module 302) may allow the user to import the content of filescreated with certain applications to a project in the projects database312. In one specific example of implementation, the user may be allowedto import the contents of such a file to a blank project template inorder to populate it with the events, tasks and roles developed in theother software application.

For example, assume that prior to using the collaboration system 10, theuser was managing his or her projects based on an Excel spreadsheet. Inthe spreadsheet, assume that:

-   -   a project event occupied a particular cell (i.e., intersection        between a row and column)    -   columns represented time periods or increments (e.g., days,        weeks or months); and    -   rows in the column represented project roles (e.g., architect,        modeler, HVAC contractor) and/or the names of the people        typically assigned to those roles.

Therefore, a person viewing the spreadsheet would find the row with hisor her name and follow it across to find the task(s) that he or she wasresponsible for that time period.

Now assume that the user wishes to build a project in the system 10based on the template he or she already has in the Excel spreadsheet.When the user is creating the project, he or she may select or indicate(e.g., via a control provided by the user interface sub-module 910) thatthere is a file (namely, the Excel spreadsheet) that contains a templatefor or example of the project he or she would like to create. The usermay also use the controls to indicate where this file is located and/orits type (e.g., Microsoft Excel or Project file).

Upon receiving such an indication, the projects module 302 may create ablank project template and then attempt to load the contents of the fileinto this template. More specifically, the module 302 may review thecontents of the spreadsheet and try to determine certain informationabout this template, including:

-   -   the probable location of one or more events (i.e., the cells        containing the events);    -   the type of event at each location (e.g., whether the event is a        timeline, task, to-do or milestone);    -   the role associated with the events; and/or    -   the name of the person associated with each role.

Should the projects module 302 complete this determination processsuccessfully, it will either transfer the information from the file tothe project template and/or recreate these events and roles in the blanktemplate. For example, the module 302 may be able to create events androles in the blank project template based on the entries in the cells,rows and columns of the Excel spreadsheet. The module 302 may alsoreview the names of the people associated with the roles to see if theyare members of the user community 14 and offer to invite those whoaren't in the community 14.

However, if the projects module 302 is unsuccessful at thisdetermination process, it may request that the user assist it, such asby identifying certain sample events and/or roles in the spreadsheet.Such an iterative process may repeat until the module 302 is able tocomplete the determination process successfully and import the eventsand/or roles from the file.

For example, the system 10 may request that the user identify certainevents and/or roles in the Excel spreadsheet with particular colors(e.g., red for timeline event, blue for a task, green for a role title).By identifying the colored cells in the Excel spreadsheet and matchingit with the event and/or role type, the module 302 may be moresuccessful at importing the events and/or roles from the spreadsheet.

When the projects module 302 performs this importing process, it does soto the best of its ability, which may result in certain mistakes (e.g.,missed or incorrect events, roles, and/or incorrectly assigned eventtypes) occurring in the resulting project or template. The user may thenreview each event and/or role imported and correct it, if necessary.

It will be appreciated that by providing a means by which a user cancreate a project or project template from an existing file, he or shemay save a considerable amount of both time and effort related to thisactivity. Such savings may allow the user to be more productive in hisor her project, thus realizing certain cost-savings and/or efficienciesfor the project.

Although a blank template is likely used to create templates for theproject templates 750, the blank template could also be used to create atraining project for training a new user. For example, the new usercould be provided with an empty training project that is based on theblank template. The new user would then be coached (either by the system10 or by a human trainer) in creating events, inviting and assumingresponsibility roles and/or creating and adjusting different types oftasks in preparation for performing the same activities in a “real”project. However, the invocation of the blank project template used tocreate the training project may be done by the system 10 (in the casewhere the training is automated) or by a human trainer who is differentthan the new user, rather than by the new user himself or herself.

FIG. 13B shows a non-limiting embodiment of a process by which theproject team is assembled, which was described briefly with respect tostep 1340 in FIG. 13A. In this respect, the steps in FIG. 13B may beseen as sub-steps of step 1340 in FIG. 13A and are numbered as such.

At step 1340A, a decision is made regarding the type of invitation to beextended for the role. More specifically, the invitation extended may bea so-called ‘open invitation’ or a so-called ‘targeted invitation’.Depending on which type of invitation is seen as being intended, certaindifferences in the team assemblage process may occur, as shown by thebranches in FIG. 13B.

An open invitation is extended to all members of a named group (e.g., acompany) and/or the user community 14 who satisfy certain minimumqualification criteria and remains available until a first memberaccepts (or is selected from a group of applicants to accept)responsibility for the role. When such an invitation is issued, theprojects module 302 and the community management module 304 may searchthe user profile database 314 to identify all users in the community 14whose profile 340 _(i) includes these criteria and alert them that sucha role is available for a project. Should only a single member from thissubset of the user community 14 accept the invitation, he or she assumesresponsibility for this role in the project. Alternatively, if more thanone member accepts the invitation, the first user may be provided withthe opportunity to choose from these applicants as to who will assumeresponsibility for the role.

In contrast, a targeted invitation is typically extended to only asingle member of the user community 14, to a non-member known to theinviter, or to a named group (whose administrator then functions as theinviter and selects a group member to be invited to accept the role). Inthis case, the first user is generally responsible for selecting themember of the user community 14 to whom the invitation is issued,although he or she may use certain features of the system 10 that willbe described below to help identify potential candidates. When atargeted invitation to assume responsibility for a role is issued to amember, the user receiving the invitation has the option to accept ordecline the role. If he or she declines the role, the first user mustthen extend the invitation to another member (who may also accept ordecline the role), and continue repeating such iterations until a memberchooses to accept responsibility for the role.

To illustrate the difference between the types of invitations, assumethat a project 710 _(i) in the projects database 312 represents anenvironmentally friendly residential condominium development.Furthermore, assume that one of the roles in the project is for a ‘GreenRoof Consultant’ who will be responsible for all events associated withthe design, construction and maintenance of the green roof for thisproject. In addition, the consultant will document activities relatedthe design and maintenance of this roof so that the development projectmay achieve some environmental certification, such as LEED.

If first user who created the project may not have experience with greenroofs (and/or consultants in this field), he or she may decide to issuean open invitation to all members in the user community 14 who satisfythe following criteria:

-   -   have at least 5 years of experience in construction;    -   have constructed at least one green roof in the past and/or is        in the process of maintaining at least one green roof currently;        and/or    -   have general experience with the LEED certification system, and        more specifically with the process of certification where        roofing is concerned.

Once the invitation is issued, the projects module 302 and communitymanagement module 304 review the user profiles 340 ₁ to 340 _(N) in theuser profile database 314 to identify all members of the user community14 who satisfy these criteria. Assume that such a search by the modules302 and 304 reveal five (5) prospective candidates for this role. Eachof these five members is alerted (e.g., via a message) that anopportunity to take responsibility for a role as a Green Roof Consultantexists and provide them with the ability (such as via a clickablebutton, hyperlink or other option) to accept the role. In addition, themodules 302 and/or 304 may provide each of the five prospectivecandidates with information regarding the project and the ability tocontact the first user to find out more information about the role(e.g., location of the development, specifications for the green roofand/or what payment can be offered for the candidate's expertise andservices).

Determining who accepts responsibility for the role may depend on howmany of the five prospective candidates choose to accept the invitation.If only one of these candidates accepts the invitation, responsibilityfor the role will typically be assumed by this member. However, if aplurality of candidates accepts the invitation, the first user may beprovided with the ability to choose from among these candidates as towho he or she wants to assume responsibility for the role. Once thefirst user makes this choice, the selected candidate typically assumesresponsibility for the role.

Alternatively, consider the case where the first user either hasexperience with green roofs or knows one or more members who couldfulfill the responsibilities of the Green Roof Consultant on thisproject. In this case, the first user will extend a targeted invitationfor this project role directly to his or her preferred candidate ratherthan issue an open invitation. As with the open invitation, the modules302 and/or 304 may provide the candidate with information regarding theproject, as well as the ability to contact the first user to find outmore information about the role (e.g., location of the development,specifications for the green roof and/or what payment can be offered forthe candidate's expertise and services).

Once the targeted invitation has been issued, the preferred candidatecan choose to accept or decline the proffered role. Should thiscandidate decline the role (e.g., because the candidate is too busy withother green roofs), the first user may select his next preferredcandidate and issue the targeted invitation to this member, who may alsoaccept or decline the role. This process continues until one candidateaccepts the role as the Green Roof Consultant.

With this in mind, it will be understood that once a decision has beenmade regarding the type of invitation(s) to be issued for each role onthe project team, the steps involved in assembling the team differslightly depending on the type of invitation. In particular, using atargeted invitation to fill one or more project role(s) is described inthe process branch defined by steps 1340B, 1340C and 1340D. In contrast,using an open invitation to fill one or more project role(s) isdescribed in the process branch defined by steps 1340E, 1340F and 1340G.The two branches of the process merge at step 1340H. All steps in eachbranch will be described in further detail below.

The steps 1340B, 1340C and 1340D define a process branch whereby atargeted invitation is issued to a member (or named group) in the usercommunity 14. At step 1340B, prospective candidates for each role on theproject team may be identified by a first user (or users). Typically,the prospective candidates may already be members of the user community14 and may also be known to the first user. For example, a user who is ageneral contractor will likely know other more specializedsub-contractors and may already have an idea of which of thesespecialized sub-contractors he or she wants participating in his or herproject.

In other cases, however, the prospective candidates may not be known tothe first user and/or may not be members of the user community 14. Forexample, a user who is a general architect for a project may want aparticular landscape architect he or she is familiar with to take on thelandscape architect role for this project, but this person is notcurrently a member of the user community 14. Alternatively, the generalarchitect may not know any landscape architects and therefore may needto identify prospective candidates in order to decide which one he orshe would like to participate in the project.

It may be recalled that the User Interface sub-module 910 describedpreviously can display the roles selection interface 1020, which may beused to identify prospective candidates for roles in a project duringthis step. FIG. 13C shows one non-limiting embodiment of this interface,presented in the context of a team viewer interface 1130 _(i) (shown inFIG. 11) for a project 710 _(i).

With respect to this figure, the team viewer interface 1130 _(i) may becomprised from the team parameters 740, for the project, and morespecifically, from the role for which each team member is responsible.For example, the interface 1130 _(i) includes such roles as a GeneralArchitect 740 _(i1), landscape architect 740 _(i2) to the role of thelast team member 740 _(iN-1), which in this denotes an architecturalmodeler.

Each instance of the team parameters displayed in the interface 1130_(i) includes the role title, a brief description of itsresponsibilities and indicates whether the role is currently assigned(i.e., a person is listed for the role) or unassigned (i.e., no personis listed for the role. In the case of a role that is unassigned, theteam viewer interface 1130 _(i) provides an Invite option (indicated initalics in FIG. 13C) that allows the first user to identify theperson(s) who could be invited to assume the role.

Selecting the Invite option typically causes the roles selectioninterface 1020 to be displayed, of which a non-limiting embodiment(i.e., the interface 1020 _(i)) is shown in FIG. 13C. The interface 1020_(i) includes a set of selection options 13C01 to 13C04 that may allowsthe first user to search for, identify and invite prospective candidatesfrom within the user community 14 (as well as those outside of thecommunity) to take responsibility for this role. The roles selectioninterface 1020 _(i) also includes controls 13C10 and 13C20 that allowthe first user to either invite the selected user (or external person)to accept the role or to cancel the selection, respectively. It will beunderstood that although the interface 1020 _(i) displays four (4)options and two (2) controls, these are provided only as an example, andthe roles selection interface 1020 may include more or less optionsand/or controls than are displayed here.

The selection options (e.g., the options 13C01 to 13C04) within theroles selection interface 1020 _(i) typically allow the first user toidentify a prospective candidate for the intended role in a number ofways, including:

-   -   searching the (user) community 14 for one or more user(s) of        interest;    -   choosing a named person or group within the community 14 that is        known to contain one or more user(s) of interest; and/or    -   selecting one or more user(s) of interest who are currently        outside of the user community 14.

In addition, the selection options may also allow the first user toassign the role to himself or herself. It will be appreciated that theabove list of selection options constitutes a non-exhaustive list asother options may exist and would fall within the scope of the presentinvention.

Should the first user choose the selection option to search the usercommunity, the roles selection interface 1020 i may display anassociated search interface 13C100 that allows the user to view andinteract with a list of the user profiles 340 ₁ to 340 _(N) that arestored in the user profile database 314.

In a non-limiting embodiment, the associated search interface 13C100displayed by the roles selection interface 1020 _(i) may appear in aso-called ‘foldout’ menu that appears to emerge from and becomesattached one of the sides of the interface 1020 _(i). FIG. 13C displaysthe associated search menu 13C100 within such a foldout menu thatappears to emerge from the right side of the team member viewerinterface 1130 _(i).

The associated search interface 13C100 includes various search controlsthat allow the first user to search the user profiles stored within theuser profile database 314 via various criteria or facets. The searchcontrols 13C110 may allow search for user(s) of interest based oncriteria that may include, among others:

-   -   a name, which may include the user of interest's first name,        last name and/or email address;    -   membership of the user(s) of interest in a named group that is        known to the first user or in which the first user is a member        (e.g., a company or non-profit organization);    -   past projects in which the user(s) of interest and the first        user participated in;    -   a geographic distance within which the user(s) of interest may        be located;    -   any qualifications or skills that the user(s) of interest must        possess, such as current accreditation with a licensing body or        experience with a particular HVAC management system;    -   a particular level of experience that the user(s) of interest        must have, which may be expressed in a time duration (e.g.,        years of experience) or as a relative standing (e.g.,        beginner/intermediate/expert/guru);    -   any professional accreditation that the user(s) of interest must        have, such as being a currently licensed architect with the        appropriate board; and/or    -   recommendations regarding the user(s) of interest that are        generally positive or negative in nature.

It will be understood that the above list of search controls isnon-exhaustive and that other controls and criteria may exist, whichwould fall within the scope of the present invention.

Those skilled in the art will appreciate that the search controls 13C110may be provided in a form that is most appropriate to the type ofcriteria searched. For example, a control to search by user profiles byuser name might be provided as a text field and/or drop-down menu, amongother options. In contrast, a control to search by level of experiencemay provide a set of checkboxes or radio buttons that allow a user tofilter according to a single experience criteria or by a plurality ofsuch criteria.

In a first non-limiting example, the first user could input the name (orpart thereof) of the user(s) of interest in the search controls 13C110,and in particular the User Name control. Should the portion of a nameentered in this control match that stored for a user profile in the userprofile database 314, the name of the user may be completed in thecontrol. This allows the first user to designate a user of interestimmediately from the search controls 13C110 rather than having to searchthrough the entire list of user profiles 340 ₁ to 340 _(N) in the userprofile database 314.

Alternatively, if the name entered in the search controls 13C110 doesnot match that stored for a user profile in the user profile database314, a prompt may appear to indicate that no matches were found and/oralternative spellings (which may be identified from the closest possiblematches in the database 314) may be provided to allow users withhomonymic spellings of their names (e.g., Larry Flynn and Barry Flin) tobe considered.

In another non-limiting example, the first user could enter or indicateparticular qualifications for the user(s) of interest via the searchcontrols 13C110, and particularly, the Skills Required control, theExperience Required control and/or the Professional Certificationcontrol, among others. In this case, the first user enters or indicatesone or more qualifications in one of the control(s) and uses the othercontrols to refine his or her initial selection. As the first user isrefining his or her selection (or alternatively, when he or she isdone), a database search key or string is generated that is submitted tothe user profile database 314, likely by the community management module304. The search key or string converts the first user's indicatedqualifications into a form suitable for processing by the database 314,such as a search query in the SQL language.

The search key or string is then submitted to the user profile database314 in order to identify those user(s) of interest who possess therequired qualifications, which may be expressed as some combination ofskills, experience and/or accreditation. The resulting list of user(s)of interest may be displayed to the user in the same interface (i.e.,the search interface 13C100) or in another interface provided for thispurpose.

In the above example, the first user was responsible for entering andspecifying the qualifications required for the role. In an alternativeembodiment, the system 10 may handle this function based on knowninformation about the unfilled role. For example, based on priorprojects, the system 10 (and more particularly, the projects managementsub-module 920) may become aware or are otherwise informed that userswho take responsibility for certain roles require certainqualifications. For example, the qualifications for general architectfor a project may require, among others:

-   -   design, drafting, budgeting, presentation and negotiation        skills;    -   at least 5 years of experience; and    -   current certification from a professional architectural body.

Based on this information, the sub-module 920 may consult the userprofile database 314 to identify prospective candidates and generate apotential short-list for the role based on these criteria even beforethe associated search interface 13C100 is accessed by the first user. Inthis way, the system 10 can anticipate the need to fill the unassignedroles and assist the first user in identifying prospective candidates.Of course, it will be understood that the first user can still refinethis list of prospective candidates further using the other searchcontrols 13C110.

Advantageously, such a manner of identifying prospective candidates forroles may allow certain specialized knowledge encoded within the systemto be used to identify candidates for a role. For example assume thatthe first user indicates that an architect with 3 to 5 years ofexperience is suitable for a project. However, the system 10 is aware ofprior knowledge indicates that an architect with 5-7 years of experiencewould be a better choice for a project of the type and scale indicated,the first user may be alerted to such knowledge, such as via a prompt ormessage. A process by which such knowledge can be extracted from usercontributions to the system 10 will be described later.

In the above embodiment, the search performed by the first user via theroles selection interface 1020 and the associated search interface13C100 was undertaken based on all user profiles 340 ₁ to 340 _(N)stored in the user profile database 314, which represents all users inthe user community 14. However, it may also be possible the first usermay want to restrict his or her search for one or more user(s) ofinterest to a particular subset of this population, such as a namedgroup that represents the employees of his or her company.

In such cases, the first user may use the roles selection interface 1020to invoke a logic that would otherwise restrict his or her search to aparticular group within or subset of the population of the usercommunity 14. For example, this user may choose the “Choose from agroup” option in the selection controls 13C1 to 13C4. Selecting thisoption would cause the associated search interface 13C100 to display asomewhat different set of the search controls 13C110 within thisinterface.

In particular, the search controls 13C110 would allow the first user toselect one or more particular named groups from which user(s) ofinterest are to be searched. For example, the first user may select thenamed group corresponding to the company or business that he or sheworks for, and/or the named group defining a particular department inthis organization. For example, assume that the first user is a civilengineer in a large engineering firm who is looking for an environmentalengineer to work on a project in such a role. Rather than search theentirety of the user community 14 (which may contain user profiles forhundreds or thousands of environmental engineers), the civil engineerchooses to restrict the search to a named group using the optiondescribed above.

As before, the associated search interface 13C100 appears as a foldoutbeside the team parameters viewer 1130 i, displaying the search controls13C110. In this case, however, the search controls 13C110 may providethe option to select by named group(s) rather than by user name(s). Togenerate the search key or string, the civil engineer first selects thenamed group for his or her company and/or the named group for theenvironmental engineering department within this organization. Thisrestricts the search to only those user profiles within the namedgroup(s). As before, the civil engineer can use the other searchcontrols 13C110 in this interface to continue refining the searchcriteria in order to more closely define the characteristics forenvironmental engineer that is his or her ideal user(s) of interest forthis role.

It will be appreciated that other subsets of the user community 14 maybe selected for a search in a manner which is generally similar to thatdescribed above. For example, a search could be conducted by the firstuser on a subset of the user community based on a certain level ofexperience and/or a particular recommendation level.

In a non-limiting example of the former case, assume that the roleselection interface 1020 includes an option based on experience, such asa “Choose based on experience” option. Upon selecting this option, thefollowing may occur:

-   -   the projects module 302 and/or the projects management        sub-module 920 may employ a certain selection logic to review        the user community 14 and identify users who would likely fall        within the subset for this role; and    -   the associated search interface 13C100 appears in a foldout as        before, but the set of search controls 13C110 provided in this        interface might be tailored to allow the first user to better        define the level of experience that user(s) of interest for this        role must have.

For example, assume that the first user is a general architect who istrying to fill a landscape architect role for his project. The projectthat the general architect is bidding on is intended as a showcaseoffice tower headquarters for a large multinational organization. Basedon this knowledge, the general architect knows that he must choose alandscape architect with considerable experience and so chooses the“Choose based on experience” option in the roles selection interface1020 _(i).

When the architect makes this selection in the roles selection interface1020 _(i) for the landscape architect role, the projects managementsub-module 920, the projects module 302 and/or the community managementmodule 304 may submit a preset search string to the user communitydatabase 314 in order to identify the subset of the user community 14that likely fits the general requirements known for this role (i.e., theuser profile 340 _(i) indicates that the user is presently a landscapearchitect and/or is currently accredited as such). Furthermore, thesub-module 920 and/or the modules 302 and 304 may sort the usersidentified by this preset search by their stated (or inferred)experience, such as by listing the most experienced landscape architectsat the top.

It will be appreciated that this preset search is likely executed at thesame time that the associated search interface 13C100 is displayed tothe general architect. The landscape architects found by the presetsearch are also likely displayed within this interface, and the set ofsearch controls 13C110 is customized to allow the architect to refinehis search of this population further. For example, the generalarchitect may specify via the controls 13C110 that the landscapearchitect(s) of interest must also have at least 10 years of experiencewith commercial development projects and/or office buildings, as well asbe located within 100 miles/kilometers of the site location in order tofacilitate communication and co-ordination during construction.

A similar process may be used to identify user(s) of interest based on auser community-generated general recommendation (or satisfaction) levelor rating that can be associated with a user profile 340 _(i). In thiscase, a first user may choose an option in the roles selection interface1020 similar to “Choose from the most recommended users”, rather thanoptions based on groups or experience as have been described previously.However, the general selection logic used by the projects managementsub-module 920 and/or the modules 302 and 304 to identify a subset ofusers from the user community 14 who generally fulfill the rolerequirements, as well as customizations to the associated searchinterface 13C100 to allow further refinements of the search, wouldotherwise be identical.

In certain cases, the user(s) of interest for a particular role in aproject may not currently be members of the user community 14. Forexample, new employees of a company that is using the collaborationsystem 10 are unlikely to have a user profile 340 _(i) unless theypreviously participated in a project using the system 10.

In such cases, the role selection interface 1020 can provide the firstuser with the ability to invite the user(s) of interest to join the usercommunity 14 and subsequently assume the project role envisioned for himor her. For example, the role selection interface 1020 _(i) provides the“Invite a person to join” option.

When this option is selected, the user is provided with controls toenter the email address of the person being invited to join thecommunity 14. For example, the associated search interface 13C100 maydisplay one or more fields that allows entry of the email address of theintended user of interest, as well as other fields to allow relatedinformation (such as a brief message or the name of the inviting user)to be entered.

By providing such options, the role selection interface 1020 allows thefirst user a variety of search and selection means to identify the bestperson to fill the available role in the project.

At step 1340C, the system 10 sends the user(s) of interest a messagealerting them that they have been selected for a role in the presentproject and inviting them to accept responsibility for this role. Themessage may be sent using the projects module 302 or the communitymanagement module 304 and may take one of several forms, depending onwhether the user is determined to be currently connected with the system10 or not.

Should the user of interest be determined to be currently connected to(i.e., logged into) the system 10 may issue a message to the user ofinterest, alerting them that he or she has been selected as aprospective candidate for a role in the project. The user may be alertedto this via a message via an interface provided in a media/messagingviewer 1140 that will be described later.

Alternatively, if the user is determined to be currently disconnectedfrom (i.e., logged out of) the system 10, the message may take one ofseveral forms, including:

-   -   an email message to an email address of the user of interest,        either as indicated in his or her user profile or to an email        address indicated by the first user, if the user of interest is        not currently part of the user community 14;    -   a text message (e.g., an SMS or MMS message) sent to the mobile        device of the user of interest, such as via an SMS server        operated by a network provider (e.g., a mobile telephone        company); and/or    -   a voice message sent to the telephone of the user of interest        via an IVR system.

It is believed that methods for determining whether a particular user(such as the user of interest) is currently connected or disconnected toa computer system and/or network, such as the system 10, are known inthe art. As a result, further discussion regarding such determinationmethods need not be provided here.

It will be further appreciated that in the case where the user profile340 _(i) contains multiple messaging means of contacting the user, it ispossible that the user may establish a priority for these means. Inparticular, the user may identify certain messaging devices as beingpreferred over other devices. For example, in the case where a userlists his or her work phone number, cellular telephone number, workemail address and mobile email address (among others), the user mayindicate that a mobile communications device (e.g., his or hercellphone) may be his or her preferred means of receiving a message.

In such cases, the message sent to the user of interest during this stepmay follow the priority set by the user. For example, if the userprofile 340 _(i) indicates that the user would prefer to be contacted bySMS first and then by email, the modules 302 and/or 304 may tryinitially sending the invitation via SMS and then wait to see if theuser responds via this messaging means. Should the user not respond tothe invitation within a certain predetermined time period (e.g., within24 hours), the next preferred messaging means (e.g., an email message)will then be used to send the invitation.

It may be appreciated that an invitation to assume responsibility for arole is sent to a named group (e.g., a company or department), theinvitation may be intended for a particular person in that group.Furthermore it is possible that when the invitation is sent, the personwho will fulfill the role from that group may be unknown.

For example, assume that an invitation for the role of “HVAC systemtechnician” is sent during the initial setup of a project to a namedgroup that represents a heating and air conditioning maintenancecompany. Since the maintenance phase events for this technician arelikely set far into the future, the actual technician who will behandling the maintenance of the HVAC system may not be known at the timewhen the invitation is issued. (In fact, it is possible that thetechnician who will actually service this equipment in the future maynot have been hired yet.)

To handle such situations, a member of each named group may be deemedthe ‘administrator’ of the group. In certain cases, the groupadministrator may be the user who initially created or set up the groupwithin the user community 14. In other cases, the group administrator'srole may be transferred among several users.

Regardless of which user in the group acts as its administrator, he orshe may receive messages (such as invitations) on behalf of the entiregroup and then forward such messages onto other group members asappropriate. In the case of invitations to assume responsibility for arole, the group administrator may forward such messages onto one or moreusers in the group for consideration.

Continuing the example above, the group administrator for themaintenance company would receive the initial invitation to assume theHVAC technician role for the project. Depending on how far in the futurethe events related to this role are set, the group administrator couldeither accept the role himself or herself and transfer it later toanother group member (i.e., HVAC technician) who will actually performthe work, or wait until a later time and forward it to the group memberwho will actually perform the work.

At step 1340D, the prospective user(s) of interest respond to theinvitation that was issued in the previous step 1340C. In particular,the user(s) of interest can either accept or decline the invitation.

It will be noted that the ability to accept or decline the invitationmay be integrated directly into the message. For example, an invitationsent via email or SMS message may include controls (such as graphicbuttons or text instructions) to indicate whether the invitation isaccepted or declined. Invitations sent as voice messages via an IVRsystem may include prompts that allow the user to indicate his or heracceptance or refusal of the invitation via the touchpad of thetelephone (e.g., “Press the star key to accept the invitation. Press thepound key to decline the invitation”).

As indicated above, an invitation issued to a group is typicallyreceived by the group's administrator, who may not be the intended userfor the invitation. Therefore, the group administrator may forward theinvitation onto one or more group members without needing to accept ordecline the invitation himself or herself.

The steps 1340B, 1340C and 1340D define a process branch whereby an openinvitation is issued to a member (or a named group) in the usercommunity 14. At step 1340E, the first user defines one or more criteriathat a prospective candidate must satisfy in order to be considered forthe role on the project. The project module 302 and/or communitymanagement module 304 will use these criteria at a later step toidentify and invite prospective candidates to accept the role.

It will be appreciated that in order to define the criteria forprospective candidates, the first user may use an interface similar tothat which has already been presented in FIG. 13C. In particular, theuser may choose the appropriate option from the team member viewerinterface 1130 _(i), such as “Send an Open Invitation to the Community”.Upon choosing such an option, the associated search interface 13C100 mayappear in a so-called ‘foldout’ that is laterally arranged aside theinterface 1130 _(i). In this way, the first user is presented with a setof similar interfaces for issuing open and/or targeted invitations,which allows a user to use these controls more efficiently regardless ofthe type of invitation being issued.

To reiterate, a significant difference between the open and targetedinvitation types is that in the former type the one or more specificusers of interest who are prospective candidates are not known to thefirst user apriori. In fact, the prospective candidates may not be knownto the first user until the member of the user community 14 accepts therole. This may be advantageous in cases where potential confidentialityand/or conflict-of-interest issues on the part of the first user makeissuing a targeted invitation difficult.

For example, a first user who is a government or military employee orcontractor may be restricted by certain conflict-of-interest laws thatprevent him or her issuing a targeted invitation to certain preferredprospective candidates. In such a case, the first user can issue an openinvitation that would likely include these preferred candidates amongothers.

Because the first user may not need to know (or, in fact, be prohibitedby law from knowing) the identity of prospective candidates for aparticular role, the associated search interface 13C100 may display asomewhat modified set of search controls 13C110. In particular, thesearch controls 13C110 may allow the user to define certain criteria forthe prospective candidates but not show the name(s) of the members ofthe user community 14 who would be included considered users ofinterest.

For example, the controls that would allow identification of one or morespecific users of interest in the search controls 13C110 (e.g., the UserName and/or Member of Group controls) may be absent or unavailable whenthe first user chooses to issue an open invitation. However, thecontrols related to qualifications, such as location, skills required,experience required and/or professional certification, may be available.

For example, for the role of a landscape architect, the first user mayidentify that prospective candidates must possess qualificationsincluding:

-   -   5 years of experience as a landscape architect;    -   at least two commercial development projects (e.g., office or        shopping mall developments); and/or    -   located within 150 km of the project site.

As the first user uses the search controls 13C110, in this way, he orshe is defining the required qualifications needed by a member of theuser community 14 in order to assume responsibility for the role. In thecontext of a targeted invitation, this would have resulted in thecreation of a search string or query submitted to the user profiledatabase 314 that resulted in the display of a list of one or moremembers in the subset of the community 14 who fulfilled these criteria.However, in the context of an open invitation, the use of these controlsdoes not display such a list, although a search string or query may besimilarly generated and submitted to the database 314.

Although the names of prospective candidates are not communicated to thefirst user in an open invitation, the system 10 may provide someindication of the number of candidates found to this user. For example,assume that a first user uses the search controls to issue an openinvitation for the role as a landscape architect and has entered thethree criteria above in the search controls 13C110. The communitymanagement module 304 submits the search query to the user profiledatabase 314 and determines that over 2,000 users in the community 14fulfill the first user's criteria. This value may cause a prompt toappear that informs the user that the number of prospective candidatesis very high. In turn, this may cause the first user to add or otherwisemodify his criteria in the search controls 13C110 to reduce the set ofprospective candidates to a more manageable number.

In the above description, the first user is responsible for defining theset of qualifications used to select prospective candidates for the openinvitation. However, it is conceivable that the associated tasks relatedto the unfilled role may themselves define a set of qualificationsand/or requirements for prospective candidates. In such a case, thefirst user may simply review and approve the set of qualification forthe open invitation rather than be directly involved in the constructionof the set of qualifications.

For example, assume that an unfilled role on a project for an officebuilding development is for a project accountant. Assume also that thecurrent project was created by the first user based on a template from aprior office building development that also included a projectaccountant role. Further assume that the project accountant role in theprevious development project required a certain set of qualifications,including:

-   -   3 to 5 years of experience in construction-related accounting;    -   located within 50 miles of the building site;    -   professional accreditation as a Chartered Accountant (C.A.); and    -   experience with planning, accounting for and submitting        documentation to support certain LEED certification activities        (e.g., providing receipts showing that 100% of the building        materials used were sourced locally).

Because the project accountant role in the current project is based on asubstantially similar (if not identical) role in a prior project, theset of qualification for the current role may already be defined. Inthis case, the first user need only review the set of qualifications toensure that they conform to his or her role expectations before issuingthe invitation to the user community 14.

It will be appreciated that even when a role includes a predefined setof qualifications, the first user has the opportunity to adjust this setof qualifications accordingly. For example, if the first user in theabove project prefers to have the project team located closer to thebuilding site, he or she could adjust the location-related qualificationso that prospective candidates would need to live within 30 miles of thebuilding site instead of 50 miles. This ability to adjust the set ofqualifications for an open invitation ensures that the first user hasflexibility to adjust the role to match his or her current project'srequirements and/or expectations rather than those of the past.

In an alternative embodiment, the first user may use the search controls13C110 to define a first set of qualifications (such as a level ofexperience) that is necessary, as well as a second set of qualificationsthat would be preferable but are not as necessary as those defined inthe first set. (These two sets of qualifications are typically referredto as ‘must have’ and ‘nice-to-have’, respectively.) By defining thesetwo sets of requirements, the first user may provide the project module302 and/or the community management module 304 with a method of sortingand ranking prospective candidates. This may allow the modules 302and/or 304 to indicate to the first user how many prospective candidatesmeet all of his or her criteria (i.e., necessary and nice-to-have)versus those that meet only some of the criteria (i.e., all must-haveand some nice-to-have). This indication may cause the first user toconsider whether his or her search conditions are too restrictive orbroad.

The result of step 1340E is the generation of a set of qualificationsidentified by the first user via the search controls 13C110 thatprospective users must meet. As in the case of the targeted invitation,the modules 302 and/or 304 convert this set into a search string orquery that can be submitted to the user profile database 314. It isworth noting that this conversion (and the submission of the searchstring to the database 314) may occur simultaneously with the user'sinteraction with the search controls 13C110 or shortly thereafter. Thus,once the first user indicates that he or she is satisfied with the setof qualifications (i.e., by clicking an ‘Invite’ button), the modules302 and/or 304 may already have identified the subset of prospectivecandidates from the user profiles 340 ₁ to 340 _(N) in the user profiledatabase 314.

At step 1340F, the open invitation is issued to the set of prospectivecandidates (or users of interest) based on the result set generated bythe search string or query submitted to the user profile database 314 inthe previous step. The open invitation may be issued using a number offorms that are substantially similar to those used for the targetedinvitation (e.g., message, email or SMS text), and therefore, theexplanation of these forms is omitted here for brevity.

It is worth noting that, regardless of the form of the invitation, itwould typically contain a control (such as a clickable button orcheckbox in the case of a message or email) that allows the prospectivecandidate to indicate his or her interest in assuming responsibility forthe project role, or for declining the role. For example, the invitationmay include an “Accept” button and a “Decline” button (or iconsrepresenting similar indications) to allow the prospective candidate toindicate whether he or she wishes to assume responsibility for the rolein the project.

Like targeted invitations, an open invitation can be issued to namedgroups as well as individual users. As described above, such aninvitation will be received by the group's administrator, who can acceptthe role on behalf of the group. Alternatively, the administrator mayforward or pass along the open invitation to one or more group memberswithout accepting it himself or herself.

It is expected that when an open invitation to accept responsibility fora role is issued, acceptance of the invitation will not beinstantaneous. In the context of many industries, prospective users mayneed time to review their current and future workloads and communicatewith the first user to obtain more information about the project, reviewthe expected workload and/or negotiate compensation, all of which may befacilitated by the media/messaging viewer 1140.

To account for such a period, the first user may be provided through thesearch controls 13C110 a control to establish an ‘acceptance period’ forthe open invitation. For example, the open invitation could be issued toprospective candidates on a Monday but such candidates would beprevented until Wednesday (i.e., 2 days later) to reply in order to givea candidate time to learn about the project and decide whether or not heor she would like to participate. On Wednesday, the acceptance periodfor the role is opened and the first prospective candidate to signal hisor her acceptance can accept responsibility for it.

By providing an acceptance period, the first user can preventprospective candidates who receive an open invitation from feelingpressured to immediately choose whether to accept or decline the offerwithout further information about the project, lest they lose it toanother candidate. In this way, responsibility for an available role canbe filled by a user who is likely genuinely interested in working on theproject, rather than someone who jumps at an opportunity and thendecides whether or not to participate.

At step 1340G, one or more of the prospective candidates respond to theopen invitation issued during the previous step. Responding to the openinvitation may be performed by in various ways, which may include:

-   -   using a control (such as a clickable button or checkbox)        embedded in a message or email to indicate whether the user        accepts or declines the role;    -   sending (or replying) to an text message from a cellular phone        (e.g., texting “Accept” or “Decline” to a particular SMS        number); or    -   replying to a IVR system prompt by keying in a particular        sequence of keys on a telephone, such as the pound (#) key        (e.g., Pressing the pound key (#) to accept the invitation or        pressing the star key (*) to decline the invitation.

Those skilled in the art will appreciated that other ways of replying toan open invitation may exist that would fall within the scope of thepresent invention.

At step 1340H, replies to invitations from the previous step aremonitored by the system 10 to determine acceptance or refusal of projectroles by their prospective team members. In particular, the projectsmodule 302 and/or the community management module 304 receive:

-   -   indication of acceptance or refusal from a user of interest for        a targeted invitation; or    -   indication of acceptance or refusal from one or more prospective        candidate for an open invitation.

In the case where the user accepts responsibility for the project rolein a targeted invitation, the projects module 302 can update theprojects database 312 to indicate that the user accepted the projectrole and so has become a project team member. This may cause the teammember viewer 1130 to be updated to indicate that the role was acceptedand list the user's name associated with the role.

In a similar manner, the community management module 304 may update theuser's profile 340 _(i) within the user profile database 314 to indicatethat the user has accepted responsibility for the invited role and hasthus become a member of that particular project. This may cause aninterface shown to the user to include the new project on which the useris now going to be working.

In the case where a user accepts responsibility for the project role inan open invitation, the projects module 302 may react differentlydepending on the number of candidates who accept the role. If only onecandidate accepts responsibility for the role, the module 302 is likelyto act in a similar way to that described for a targeted invitation. Inthis case, the projects module 302 and/or community management module304 would update the databases 312 and/or 314 (and or the team memberviewer 1130) to indicate that the prospective candidate accepted theproject role and so has become a project team member.

On the other hand, if an open invitation results in a plurality ofprospective candidates who indicate that they would like to accept therole, the projects module 302 may use a determination process to decidewhich of these candidates will assume responsibility for the role.

For example, a list of the candidates who indicated their acceptance ofthe role may be provided to the first user in a message to allow him orher to make the final choice as to who should be allowed to acceptresponsibility for the role. When the first user indicates his or herchoice for the role (e.g., by clicking a checkbox or radio button), theprojects module 302 may communicate this choice to the winning candidate(and/or losing candidates), as well as updates the projects database 312(and or the team member viewer 1130) to indicate that the winningcandidate has become a project team member in the indicated role.

Alternatively, the projects module 302 (or the projects managementsub-module 920) could use an automated selection process that comparesthe prospective candidates based on certain criteria and decides whichof these candidates would be the best choice for the role. Criteria thatcould be used for such a selection process may include (among others):

-   -   how well each candidate's set of qualifications match up to the        set of qualifications determined for the role;    -   what the current (and expected future) workload for each        candidate is (or is expected to be), based on their involvement        with projects in the projects database 312; and/or    -   how satisfied (or dissatisfied) other users have been with the        work of each candidate, as indicated by the tagging sub-module        650.

It will be appreciated that the above list of criteria is non-exhaustiveas other possibilities exist and would fall within the scope of thepresent invention.

One possible result of the automated selection process described abovemay be the identification of a prospective candidate that the projectsmodule 302 (or the sub-module 920) finds is the ‘best fit’ for theavailable role. In certain cases, this determination may allow themodule 302 to decide on the winning candidate for the role and updatethe projects database 312 (and team member viewer 1130) accordinglywithout any further human involvement.

Another possible result of the automated selection process describedabove may be the development of a so-called ‘short-list’ of possiblewinning candidates for review by the first user. For example, theprojects module 302 may identify the three (3) best candidates using theselection process and then provide the first user with the ability tochoose the winning candidate from among these three. Allowing theautomated selection process to review the set of prospective candidateswho indicated their interest in the role may improve the efficiency andproductivity of the first user in cases where the set of prospectivecandidates may be large. For example, if an open invitation results in62 candidates indicating their interest in the role, it may be moreefficient for the first user to allow the projects module to identifythe three or five best candidates. Otherwise, the first user would haveto review all 62 candidate user profiles, which may be an inefficientuse of his or her time.

Yet another possible result of the automated selection process describedabove may involve a run-off process, whereby each prospective candidatewho indicated their interest in the role may be invited to demonstratetheir level of interest and/or qualifications. For example, the projectsmodule 302 could ask each candidate to indicate their expected level ofcompensation for his or her involvement in the project. Alternatively,the module 302 could provide each candidate with a sample problem thatthe candidate must solve. The result of this run-off process may beeither the selection of the winning candidate or the development of ashort-list of potential winning candidates to be provided to the firstuser.

Regardless of the type of invitation issued (and/or the way that theprospective candidate was selected), the result of the selection processdescribed above is that the projects module 302 may update the projectsdatabase 312 to indicate that the user accepted the project role and sohas become a project team member. In a similar manner, the communitymanagement module 304 may update the user's profile 340 _(i) within theuser profile database 314 to indicate that the user acceptedresponsibility for the invited role and has become a member of thatparticular project. This may cause the team member viewer 1130 to beupdated to indicate that the role was accepted and list the user's nameassociated with the role.

On the other hand, if the user(s) of interest decline the invitation toaccept responsibility for the role offered in a targeted invitation,another user may be invited by the system 10 to accept responsibilityfor the role. In particular, when the projects module 302 and/orcommunity management module 304 receive a user's refusal to takeresponsibility for the project role, one or both of these modules mayalert the first user (who had initially selected the invited user) ofthis development. As a result, a new iteration of the process outlinedby FIG. 13B commences with the first user commencing a search toidentify another user(s) of interest to accept responsibility for theproject role.

The refusal of a role by a prospective candidate for an open invitationmay also be noted by the projects module 302 and/or community managementmodule 304. In this case, however, the modules 302 and/or 302 are morelikely to deal with conditions of acceptance, and more specifically thesituation whereby a plurality of users indicate interest in a role.Should all prospective candidates for an open invitation refuse toaccept responsibility for a role, the projects module 302 and/orcommunity management module 304 may indicate this result to the firstuser. This action may result in a new iteration of the process outlinedby FIG. 13B with the first user possibly responding in a variety ofways, including:

-   -   issuing a targeted invitation to one or more users; and/or    -   refining the set of qualifications in the open invitation to        make it more inclusive (i.e., include more prospective        candidates).

It will also be appreciated that the issuance of an invitation tofulfill a role regardless of whether the invitation was targeted or open(and the subsequent receipt of a reply to this invitation) comprises atask event related to the project, not just a message sent betweenusers. In particular, when an invitation is issued by the first user, arelated task event is created for him or her that must be completed.More specifically, a task relating to the invitation is created withinthe event group 730 of the project and remains uncompleted until someone(i.e., the first user or a user of interest) accepts responsibility forthe role. Once the invitation is accepted by a user (regardless of howmany iterations of the process outlined in FIG. 13B are required to doso), the task is considered completed.

Because the invitation is perceived by the system 10 (and moreparticularly the projects module 302) as a task event rather than simplyas a message, identifying which roles are currently unfilled isconsiderably simplified, since an unfilled role is seen by the system 10as the equivalent of an uncompleted task event. This approach helpsreduce the possibility that unfilled project roles will remain unfilleddue to oversight (e.g., the first user forgets to check that all of theroles are filled) or communication problems between the first user andthe user(s) of interest (e.g., email issues prevent the invitation frombeing received).

It will be appreciated that the above messages relating to theinvitation of a member of the user community 14 to assume responsibilityfor a role, as well as the member's subsequent response indicating hisor her acceptance or refusal, are examples of task-relatedcommunications. As used here, the term “task-related communications”refers to communications (which may comprise both synchronous andasynchronous forms of communications such as internal messages and/oremail) that are associated with a particular activity.

In a non-limiting embodiment, each event comprised in a project in theprojects database 312 may have one or more instances of suchtask-related communication associated with it. For example, a targetedinvitation to accept responsibility for a particular role on a projectis an event that may be associated with the following task-relatedcommunications:

-   -   an invitation message advising a user of interest that he or she        has been invited to accept responsibility a certain role on a        project;    -   a reply email from the user of interest to the first user        requesting certain information related to the project and role;    -   an SMS text message from the first user back to the user of        interest asking him or her to call the first user and suggesting        a time for the call;    -   a voicemail message from the user of interest to confirm the        time of the call;    -   an audio recording of the VoIP conversation between the first        user and the user of interest;    -   an email from the first user confirming the contract terms and        compensation for the work of the user of interest on the        project; and    -   a reply to the invitation message indicating that the user of        interest would accept responsibility for the role.

It will be appreciated that since all task-related communications aretypically associated with an event, a user of the system 10 can organizehis or her communications according to its associated event. Byproviding an explicit link between a work activity and thecommunications associated with that activity, the user may review his orher work related to an event by looking at its related communications.Such an ability to view a work activity as a communications threadbetween the user and other members of the project team (among others)may realize certain cost- and/or productivity efficiencies.

The result of FIGS. 13A, 13B and 13C is the preparation of a projectwithin the system 10 and the assembly of its associated team from theuser community 14. It will be appreciated that growth of the usercommunity 14 may occur from users joining the system 10 by being invitedto assume responsibility for roles by existing users within thecommunity 14. It will also be appreciated that once a user isparticipating in the user community 14 through a role in a certainproject, it is becomes more likely that the user will find otherlike-minded users in the community 14 who will invite him or her toparticipate in other projects. As a result, the benefits to each user ofparticipating in the user community 14 are advantageously reinforced, asis the interest in inviting other prospective users to join.

Once a user has joined the user community 14 (i.e., they have a userprofile in the user profile database 314) he or she can access thesystem 10 in order to work one or more projects in his or her acceptedrole. Since there typically is a plurality of projects stored in theprojects database 312, each of which having a generally differentproject team, there is a need to authenticate users of the system 10 inorder that each user may see his or her projects (and its associatedevents and tasks).

FIG. 14A shows a non-limiting example of an authentication UI 1410 thatmay be used to authenticate users of the system 10. The authenticationUI 1410 is comprised of a user name/email address field 1412, a passwordfield 1414, a login control 1416, a new user indicator 1418, and anoption to store user settings 1420.

The user name/email address field 1412 and password field 1414 areintended for an existing user to enter his or her authenticationdetails, such as his or her email address (or user name, if different)and password, respectively. The login control 1416 (which can berepresented by a clickable button) allows the entered authenticationdetails for a user to be verified by the system 10, and morespecifically to be compared by the community management module 304against such details stored in the user's profile 340 _(i). Since suchauthentication are believed to be well known in the art, further detailsregarding this process need not be provided here.

The new user indicator 1418 (which may also be represented by aclickable button or checkbox, among other possibilities), allows theuser to indicate to the system 10 that he or she is a new user without auser profile. Providing such an indication from the authentication UI1410 allows the system 10 to immediately follow the process outlinedpreviously in FIG. 12 to create a user profile in the user profiledatabase 314 for the new user.

The option to store user settings 1420 is provided to retain certainentered authentication details within the authentication UI 1410 (suchas the content of the user name/email address field 1412 and/or thepassword field 1414) for future access attempts. For example, enablingthis option (e.g., by clicking the checkbox) allows the user to storehis or her user name or email address within the field 1412, so that infuture login attempts, this information will appear automatically withinthe authentication UI 1410. Such details may be stored locally with theclient 16 (e.g., within a so-called ‘cookie’ on the user's system) or onthe central node 18. Since it is believed that the storage of suchauthentication details as user names and/or passwords is known in theart, further details regarding this need not be provided here.

Once authentication details entered in the authentication UI 1410 areauthenticated by the system against his or her user profile within theuser profile database 314, the user may be provided access to a userinterface 1430 that provides access to his or her projects and relatedtasks, gives details about the team assembled for each project, allowsthe user to contact other users that may be working on the sameproject(s), as well as provides access to the user community 14 beyondthe members of the one or more project team(s).

In particular, the UI 1430 is comprised of a set of UI elements,including:

-   -   a projects UI 1440 that lists a user's projects and provides        certain details about such projects;    -   a time UI 1450 that lists tasks related to one or more projects        displayed in the projects UI 1440;    -   a team UI 1460 that lists members of the project team that has        been assembled for the one or more projects on which the user is        working;    -   a media/messaging UI 1470 that lists messages sent or received        by the user from other users in the community 14 and/or from the        system 10 itself; and    -   a community UI 1480 that provides the user with access to the        user community 14 as a whole.

Further details about each of these UI elements will be provided below.It will be appreciated that the UI elements displayed above constitute anon-exhaustive list as other elements may exist and would fall withinthe scope of the present invention.

In addition, the UI 1430 includes a set of navigation controls 1490 thatallow the user to navigate between the various UI elements 1440 to 1480.In particular, the navigation controls 1490 (which may be represented asclickable buttons with associated keyboard shortcuts) may allow a userto navigate more quickly and efficiently throughout the various UIelements in the UI 1430.

It will be appreciated that the display device used to display the UI1430 may be incapable of showing the UI 1430 in its entirety in certaincases. For example, a user viewing the UI 1430 on the smaller screen ofa cellular phone may only be able to see a portion of this UI at anytime. To assist the user in navigating the UI 1430, the navigationcontrols 1490 may be rendered in such a way that the user's currentlocation within this UI is indicated.

One example of such an indication may be visual indicators, and inparticular, the use of particular shades or colorings to indicate thecurrently visible portion of the UI 1430. For example, the controls 1490may show the currently visible portion of the UI 1430 in a darker shadeof a particular color, while the non-visible portions of the UI 1430would be represented by a lighter shade. The use of such visualindicators may allow the user to better identify how much of the UI 1430they are seeing.

Those skilled in the art will appreciate that alternative types ofindicators may be used in a similar fashion. For example, audibleindicators could be used to generate a particular sound whenever theuser displays a UI element 1430 to 1480. Similarly, tactile indicatorscould generate a vibration at the boundaries of any of one of the UIelements 1430 to 1480 and/or for the boundaries of the UI 1430 itself.Use of these various types of indicators in combination could allow auser who is visually- or audibly-challenged to utilize the system 10.

The UI 1430 also comprises a set of controls 1495 that provide certainfunctionality to a user that are independent of the UI elements 1440 to1480, which will be discussed in more detail below.

The UI 1430 further comprises a logout control 1497 that serves tologout the user when activated, thereby ending the session between thesystem 10 and the user. When this control is used, it is likely that thelogin screen 1410 may be re-displayed to the user.

It will be appreciated that the UI elements 1440 to 1480 within the UI1430 are presented laterally (i.e., beside each other) within the samescreen area. Therefore, the navigation controls 1490 can allow a user toswitch between the elements in the UI 1430, by making one of the UIelements 1440 to 1480 the primary element on the screen, while makingthe remaining UI elements secondary. Arranging UI elements laterally inthe UI 1430 reduces the need to display each of the elements 1440 to1480 within a separate frame or window, which may be confusing andinefficient, for the user. Instead, the user may use the navigationcontrols 1490 to view and quickly navigate between all elements 1440 to1480 within the single UI 1430.

In addition, interfaces related to or associated with the elements 1440to 1480 (e.g., foldouts similar to the associated search interface13C100 described previously) may also be presented in the UI 1430.Typically, associated interfaces are located in lateral proximity to theUI element from which they were called. For example, a foldout for thetime UI 1450 that describes one or more events or tasks for a projectmay be displayed in the UI 1430 beside (i.e., to the left or right of)the UI element 1450.

Furthermore, it will be appreciated that the UI 1430 represents adisplay with a generally fixed amount of space. Although the navigationcontrols 1490 allow movement through this space, certain restrictions onthe display of associated interfaces (such as foldouts similar to theassociated search interface 13C100) may be applied to ensure that the UI1430 does not become overly cluttered.

For example, the number of associated interfaces displayed at any onetime for each of the UI elements 1440 to 1480 may be limited to aparticular value, such as three (3) foldouts. For example, the time UIelement 1450 could be limited to displaying three (3) foldouts thatprovide details for, or ancillary information about, a maximum of threeevents. Should a user attempt to open a fourth foldout, the display ofone of the three original foldouts may become hidden and the user may beprompted that he or she is limited to viewing three (3) foldouts at atime for each UI element.

Alternatively, the total number of associated interfaces may be limitedfor all of the UI elements 1440 to 1480 in the UI 1430. For example, allelements 1440 to 1480 may be limited to a total of three (3) associatedinterfaces, regardless of which UI element generated the foldout. Forexample, if two (2) associated interfaces were generated from projectsin the project UI element 1440 and the user attempts to generate anothertwo (2) foldouts from events in the time UI element 1450, one of thefollowing results may occur:

-   -   one of the project UI related foldouts may be hidden;    -   one of the time UI-related foldouts may not appear;    -   the user may be prompted that he or she is limited to viewing        three (3) foldouts for the UI 1430 as a whole.

In the above examples, the numeric value defining the upper limit on thenumber of associated interfaces (or foldouts) for the UI 1430 and/or theUI elements 1440 to 1480 was set at three (3). However, this value isprovided as an example only and the actual value defining this upperlimit on foldouts may, in fact, be set lower or higher than this value.

When a user displays a plurality of foldouts in the UI 1430, it isconceivable that he or she may be more interested in one particularfoldout within this set. In this case, the user may be provided with aparticular control, such as but not limited to a button, icon (e.g., a‘pin’) or key-combination, that establishes a hierarchy within the setof foldouts for each UI element. More specifically, when the useractivates the hierarchy-related control within the UI of a particularfoldout, the selected foldout is elevated in the hierarchy and is movedcloser to its relative UI element to indicate its new position.

For example, consider the case where a user has opened three foldoutsfor the UI element 1440 that appear as follows: a first foldout locatedclosest to the element 1440, a third foldout located farthest away fromthe element 1440 and a second foldout, which is located between thefirst and third foldouts. Because the user considers the content in thesecond foldout as more useful or relevant to their work than that of thefirst and/or third foldouts, the user activates the hierarchy-relatedcontrol for this foldout (e.g., clicks a ‘pin’ icon).

When the user activates this control, the relative visual positions ofthe first and second foldouts are switched (i.e., the first foldoutbecomes the second and vice-versa), while the position of the thirdfoldout remains unchanged. This allows the user to more easily find,consult and utilize the content of the formerly second foldout for theirtask(s), while keeping the content in the other two foldouts availablefor consultation if necessary.

In addition, should the user open another (i.e., fourth) foldout fromthe UI element 1440 that exceeds the maximum number of foldouts, thesystem 10 may choose to close one of the foldouts that is lower in thefoldout hierarchy. In this case, the system 10 may close the thirdfoldout and make the newly-opened foldout the third foldout.

It will be appreciated that certain restrictions may be placed on theuse of the foldout hierarchy control described above. For example, theuser may only be allowed to elevate one (1) foldout per UI element inthe hierarchy. If the user has already elevated a first foldout and thenproceeds to elevate another, second foldout, the previously elevatedfoldout will be depreciated in the hierarchy and may be hidden orclosed.

FIG. 14B shows that the UI 1430 and its comprising UI elements 1440 to1480 are generally displayed laterally. However, the UI 1430 (or aspectsof this UI, such as one or more of the elements 1440 to 1480) could bepresented in an alternative way, such as in a polygon or polyhedron. Forexample, the UI 1430 could be displayed as a three-dimensionalfive-sided polygon with each UI element 1440 to 1480 occupying one ofits sides. In such a case, the navigation controls 1490 allow the userto control the rotation of the polygon to identify which of elements ofthe UI elements 1440 to 1480 is facing the user. Those skilled in theart will appreciated that the UI 1430 may appear in otherrepresentations and that those would fall within the scope of thepresent invention.

Furthermore, it will be appreciated that certain interfaces associatedwith the UI elements 1440 to 1480 (such as the foldout for theassociated interface 13C100 described previously with regard to FIG.13C) may be displayed in a similar fashion as these UI elements. Forexample, an interface associated with the team UI 1460 may appear as aUI element displayed laterally between the main UI 1460 and themedia/messaging UI 1470. Alternatively, the team UI 1460 may appear as athree-dimensional polygon when associated interfaces are displayed forthis UI.

Further details of the elements of the UI 1430 described above will nowbe provided. It will be appreciated that the display of each UI elementin the set of elements 1440 to 1480 is typically handled by the UIsub-module 910. Furthermore, it is likely that these elements correspondto one or more of the elements previously introduced with regard to FIG.10, and more importantly, the project management interface 1050.

FIG. 15A shows a non-limiting embodiment of the projects UI element 1440comprised within the UI 1430. The projects UI 1440 is comprised of amenu 1510 and a so-called “time pod” 1520 that displays current projectsfor which the logged-in user has accepted one or more roles.

The time pod 1520 is comprised of a set of projects 1522 ₁ to 1522 _(N)in which the user is participating and/or has participated in the past.A project 1522 _(i) within this set may be comprised of certaininformation, including:

-   -   a project title 1524 that lists the title of the project;    -   a summary information section 1526 that provides an overall        summary of the project and the user's tasks or events within        that project; and    -   a graphical information section 1528 that provides similar        information to the summary information section 1526 but in a        graphical form, such as a chart or graph.

The menu 1510 in the projects UI 1440 provides a set of options (whichmay be represented as clickable buttons or hypertext links) that mayadjust the display in the projects area 1520. More information aboutthis menu will be provided below.

The elements of each project 1522 _(i) may also be clickable elements(e.g., clickable buttons or hyperlinks) that cause certain informationto be displayed in the UI 1430. For example, clicking the project title1524 of a particular project may cause its details to appear in anassociated interface in a ‘foldout’ interface that is substantiallysimilar to the associated search interface 13C100 described earlier.This foldout interface may display certain overall information about theproject, such as the date it was created, what role(s) the user isassigned in this project, the number of overall tasks in the project(which may also be broken into design/construction/maintenance phases),and overall percentage completion of the project.

The associated foldout interface may also provide the user with optionsthat allow him or her to adjust the amount of information displayed inthe summary information section 1526 and/or graphical informationsection 1528, including:

-   -   the ability to define the tasks displayed in the summary section        1526 (e.g., only show events that are either currently due or        are late); and/or    -   the ability to adjust the type of graph displayed in the        graphical information section 1528, such as changing the bar        graph to a pie chart, and/or the ability to change the color        scheme used for events, among others.

The summary information section 1526 and/or the graphical informationsection 1528 may also comprise one or more clickable element(s), such asa hyperlink. In one embodiment, clicking a portion of the sections 1526or 1528 could display a list associated events within the time UIelement 1450, which will be described later. For example, clicking theelement in the summary information section 1526 marked “Late” maydisplay late events within the time UI element 1450.

Alternatively, clicking an element in the summary information section1526 or graphical information section 1528 may display an associatedinterface (i.e., a ‘foldout’ interface substantially similar to theinterface 13C100 described earlier with regard to FIG. 13C) that liststhe events associated with the element clicked. For example, clickingthe element in the summary information section 1526 marked “Late” maydisplay late events in the associated foldout interface that appearsproximate to the projects UI element 1440.

Typically, the projects listed in the project UI element 1440 for aparticular user may be individual projects that are unrelated to eachother. Alternatively, one or more of the projects listed in this UIelement may belong to a ‘portfolio’ that defines a relationship betweenthem. As used here, the term portfolio may refer to at least twoprojects in the projects database 312 that are related by certaincriteria, including:

-   -   a shared location, such as a set of buildings on an university        campus or those comprising a company campus (e.g., the        GooglePlex in Mountain View, Calif.);    -   a shared design (e.g., a set of bank branches or coffee shop        franchise locations) that, other than their location, are        designed in a substantially similar manner to each other and may        also be constructed and/or maintained in exactly the same way        using the same set of components.

Projects are typically designated as belonging to a portfolio when theyare created via the project type selection interface 1010. For example,the interface 1010 could provide a control (e.g., a drop-down list) thatallows a new project to be associated with another, existing project andthus become a member of a portfolio. Alternatively, if a new project iscreated by copying or ‘cloning’ another current or past project, the newproject may be considered to be a member of a portfolio since it issubstantially similar to the earlier project.

The project type selection interface 1010 (and/or the projects UIinterface 1440) may also provide certain management functionality for aportfolio. For example, a portfolio may be named (e.g., “ShanghaiUniversity campus”) and/or certain identifying features (e.g., certainicons, colors or fonts) for its member projects could be displayed inthe time pod 1520 of the projects UI element 1440.

Besides the above, the projects UI 1440 may provide some functionalityto group one or more projects belongs to the same portfolio so that thisrelationship is more evident. Although the functionality of the menu1510 will be explained later, the menu 1510 may allow the time pod 1520to be appear in a tree/branch format that may include expandablebranches for projects and portfolios.

In this way, a user could view a list of his or her projects byexpanding the Projects branch and view a list of his or her portfoliosby expanding the Portfolios branch. In addition, the list of portfoliosincluded in the Portfolios branch may be shown as their own expandablesub-branches whereby clicking one of these sub-branches can display theprojects grouped under the portfolio. As a result, a user can beprovided with a way to drill-down and see which projects are included ina particular portfolio.

FIG. 15B shows a non-limiting embodiment of the time UI element 1450comprised within the UI 1430. The time UI 1450 is comprised of a menu1530 and an events area 1540. The events area 1540 is further comprisedof a summary information section 1542 and a set of events 1544 ₁ to 1544_(N) that correspond to the tasks and events for which the user isresponsible.

By default, the events area 1540 displays all of the tasks 1544 ₁ to1544 _(N) for which a user is responsible. In the case where a user hasassumed responsibility for a plurality of roles in multiple projects, itwill be appreciated that this list may comprise hundreds of events, eachof which may represent a task requiring a user's attention at somepoint. Thus, certain controls must be provided in the time UI 1450 toallow the user the ability to filter and organize the events 1544 ₁ to1544 _(N) to prevent him or her from being overwhelmed.

The summary information section 1542 can be used to organize the events1544 ₁ to 1544 _(N) in the events area 1540. In particular, this sectioncomprises a list of general event types (such as events that areupcoming and/or late), where each event type is associated with a figureshowing the number of events associated with that type. For example, inthe illustrated UI, the user has completed 16 events, has three (3)events that are late, and has five (5) events that are due to startsoon.

Like the summary information section 1526 described previously, elementsin the summary information section 1542 may also be clickable elementse.g., clickable buttons or hyperlinks) that allow the user to displaythe events associated with a particular event type. For example, theuser may click the “Late” event type in the section 1542 to displayevents that are identified as being late. By using these elements theuser may be provided with a degree of control over the display of theevents 1544 ₁ to 1544 _(N) in the events area 1540.

Although the summary information sections 1526 and 1542 displaysubstantially the same information, it is worth noting that the formersection 1526 lists events of a certain type for which a user isresponsible for a single project. In contrast, the latter section 1542may display all events of a certain type for all projects in which theuser is participating, for a subset of projects in which the user isparticipating and/or for a single project in which the user is aparticipant.

The menu 1530 may be similar to the menu 1510 in the projects UI andwill be described in more detail below.

Once the user has displayed a certain subset of events from the events1544 ₁ to 1544 _(N), certain information about such events may bedisplayed in the events area 1540. For example, for each eventdisplayed, the events area 1540 may display (among others):

-   -   a brief description of the event;    -   the event type (e.g., milestone, document or task);    -   the phase to which an event belongs (e.g., the building phase        events 820);    -   the person(s) responsible for the event's execution, if more        than one user is responsible for the event;    -   the date and time when the event is due to occur or be        performed;    -   the status of the event; and/or    -   the estimated (or actual) duration of the event, which may be        expressed in a certain time period, such as minutes, hours,        days, weeks or months.

Depending on the type of event, the status of an event in the events1544 ₁ to 1544 _(N) may correspond to one of the following states,including:

-   -   Acknowledged (or Not Acknowledged), such as for an event that        includes a message (e.g., an invitation to participate in a        project);    -   Yes/No, such as for an event that requests the user's opinion on        a certain topic (e.g., “Should the building's façade be colored        green or aquamarine?);    -   Accepted/Declined, such as for an event requesting the user's        participation (e.g., a meeting request); or    -   Task Started or Done, which is a particular status used for task        events and is described in more detail below.

It will be appreciated that the above list is non-exhaustive in natureas other types of statuses may exist and fall within the scope of thepresent invention.

The Task Started status is reserved for a task which the user isresponsible and on which he or she is currently working. The status maybe assigned by the user himself or herself (e.g., through a clickablebutton) or by the system 10 itself through monitoring the activity ofthe user. For example, assume that a particular event represents adocumentation task to develop a PowerPoint™ presentation explaining howthe building to be constructed will qualify for a particularenvironmental certification, such as LEED.

The user creates an initial version of the presentation and associatesit with the task, such as by uploading a file entitled“LEED_Presentation_V1_Draft” to the system 10. Through this association,the system 10 may come to realize that the user is currently working onthis documentation task, and therefore assign it the “Task Started”status accordingly.

In certain cases, the user may decide that a current or an upcomingevent in the events 1544 ₁ to 1544 _(N) needs to be adjusted in somerespect. For example, assume that a certain event represents a timelineduring which the user is expected to travel to London, England tooversee initial construction on a new building. However, unforeseenevents (such as a family emergency or natural disaster) cause the userto miss his or her flight. In such a case, the user may be able toadjust the expected start date of the task based on when he or she isable to rebook a flight to London.

In particular, a user may be provided with a set of adjustment controls1546 related to a particular event in the events 1544 ₁ to 1544 _(N).Such controls may be displayed when the user performs a certain action(e.g., clicking the title of the task) or may be displayed using akeyboard shortcut or the like.

In one embodiment, the adjustment controls 1546 may provide the userwith the ability to adjust when an event occurs. For example, thecontrols 1546 that are illustrated for the task titled “Gather Intentsand Requirements” in FIG. 15B may allow the user to move (or ‘jog’) theevent backwards or forwards in time. Returning to the previous example,if the timeline event representing the user's travel to London is due tobe start in the near future, use of the adjustment controls 1546 mayallow the task to be postponed accordingly to when he or she can rebooka flight.

Alternatively, if an event is scheduled to have begun (or already becompleted) and is running late, a user can use the adjustment controls1546 to jog the event to a time when the event can be performed. Forexample, assume that a set of tasks are identified as late due to adependency on another person who has been off sick for a week. To adjustthe time when these tasks will be performed, the adjustment controls1546 can be used by the user to postpone the start times of these eventsby a week to account for the other person's absence.

The adjustment controls 1546 may also be used to change the status of atask. For example, the controls 1546 may be provided with a button orother graphical element representing different statuses to which thetask may belong. For example, the controls 1546 may provide a “TaskStarted” button so that a user can indicate to other project teammembers (as well as to the system 10 in general) that he or she hasstarted the task. Once the user has finished the task, he or she maythen use the “Done” button in the adjustment controls 1546 to update thetask's status to indicate it is complete (i.e., assign the “Task Done”status to the event).

FIG. 15C shows a non-limiting embodiment of the (project) team UIelement 1460 comprised within the UI 1430. The team UI 1460 is comprisedof a menu 1550 and a team area 1560 that includes a sub-menu 1562 and ateam member summary area 1564 that lists a set of users 1566 ₁ to 1566_(N) that comprise the members of one or more project teams in which theuser is also participating.

By default, the team UI 1460 displays all users for all project teams inwhich the current user is also a participant. As a result, the set ofusers 1566 ₁ to 1566 _(N) that are displayed in the team member summaryarea 1564 may be considerable, especially if the current user is amember of a plurality of projects. Therefore, certain controls may needto be provided in the UI 1460 in order to allow the current user toorganize the summary area 1564 so that a subset of the users 1566 ₁ to1566 _(N) is displayed in which the user is interested.

The menu 1550 is substantially similar to the menus 1510 and 1530introduced earlier and will be described in more detail below.

It may be appreciated that information related to each user in the setof users 1566 ₁ to 1566 _(N) displayed in the team member summary area1564 of the team area 1560. In particular, information regarding eachdisplayed user may include, among others:

-   -   an indication of whether a user is logged into the system 10,        such as through a colored icon;    -   an indication of each user's current role and/or their current        location (e.g., “architect/Montreal, Canada”);    -   an indication of the estimated workload of a user, which may be        provided either textually (e.g., “Tasks: 24”) or in a graphical        nature, such as a chart showing different colors for completed,        upcoming and late tasks.

The sub-menu 1562 may provide certain context-sensitive functionality toa user that is related to the subset of the users 1566 ₁ to 1566 _(N)displayed in the team member summary area 1564. For example, thesub-menu 1562 may provide a clickable control (e.g., a button orhyperlink) that may allow the current user to reload the contents of thesummary area 1564.

The sub-menu 1562 may also allow the current user to contact one or moreof the displayed users in the summary area 1564, such as via an internalmessage, email, SMS text message or VoIP phone call. Moreover, theindication of whether a user is logged on in the team member summaryarea 1564 may also provide an indication to the current user of thelikely success of a particular mode of communication. For example, auser may choose to send an email or text message to a user in thesummary area 1564 who is listed as being offline (i.e., not logged in)rather than attempt to send a message or place a VoIP phone call.

The sub-menu 1562 may also provide the current user with the ability tosearch for users not listed in the users 1566 ₁ to 1566 _(N), whichincludes users in the user community 14 who are not currently part ofany project team on which the current user is a participant. Forexample, a user may use this functionality to identify prospectivecandidates for a project role that was filled but has become availabledue to turnover. In this case, the sub-menu 1562 could display theassociated search interface 13C100 that was described in relation toFIG. 13C previously.

It will be appreciated that the list of users 1566 ₁ to 1566 _(N) in theteam member summary area 1564 may itself be comprised of clickableelements that display certain information about the user. For example,clicking the name of a user in the summary 1564 may display certaininformation about the user from his or her user profile 340 _(i) in theuser profile database 314. Such information may include his or hercontact details (if publicly available), details about the user's skillsand experience, a portfolio of the user's past projects (which may begenerated by the portfolio interface 1060) and/or a photograph of theuser. This information may be displayed in an associated interface (or‘foldout’) that is substantially similar to the associated searchinterface 13C100 described previously with regard to FIG. 13C.

FIG. 15D shows a non-limiting embodiment of the media/messaging UIelement 1470 comprised within the UI 1430. The media/messaging UI 1470is comprised of a menu 1570 and a message area 1580. The message area1580 is further comprised by a sub-menu 1582 and a set of messages 1584₁ to 1584 _(N).

The set of messages 1584 ₁ to 1584 _(N) in the message area 1580 showsall messages sent to or received by the current user from users withinthe system 10 (i.e., those users within the user community 14), as wellas possibly by users outside of the system 10.

It may be appreciated one or more messages within the set of messages1584 ₁ to 1584 _(N) may include messages sent or received in a varietyof media, including:

-   -   text messages, such as internal messages (which may be similar        to messages sent via “instant messaging”), email messages or SMS        text messages sent between two or more users;    -   audio messages, such as voicemail messages, telephone calls or        conference calls conducted over a VoIP system (e.g., Skype)        between two or more users, or audio recordings saved as digital        audio clips (e.g., in MPEG-layer 3 Recordings); and/or    -   video messages, such as video conference calls between two or        more users or recordings of avatar conversations that took place        within a virtual world (e.g., a seminar conducted within the        world of Second Life).

It will be appreciated that the set of messages 1584 ₁ to 1584 _(N)displayed in the messaging area 1580 may be substantial, especially if auser is involved in a plurality of projects where communication andcollaboration are implemented via the system 10. Therefore, it isimportant that the media/messaging UI 1470 provide a user with theability to organize and manage their messages in a variety of ways.

The menu 1570 may be substantially similar to the menus 1510, 1530 and1550 introduced earlier and will be described in more detailbelow.media/messaging UI 1470

The sub-menu 1582 within the messaging area 1580 typically providescontext-sensitive functionality related to the messages displayed in thearea 1580. For example, the user may use the sub-menu 1582 to groupprojects according to certain criteria, including (among others):

-   -   the type of message (e.g., voicemails, emails, text messages or        video conference recordings);    -   the user or named group from which the message was sent (or        received);    -   the date when the message was sent or received; and/or    -   the status of any task related to the message (e.g., task        started or task completed).

In another alternative embodiment, the sub-menu 1582 may also allow thecurrent user to view certain statistics relating to their messages, suchas the percentage of received (or sent) messages relating to anyparticular project, team, named group or particular user. Suchstatistics may allow the current user to identify particular projects,project teams (or individual users) that require substantially morecommunications to ensure collaboration occurs.

The sub-menu 1582 may also allow the current user to organize and searchthrough the message subset to identify messages of importance orrelevance. For example, the sub-menu 1582 may allow the user to switchbetween sent messages and received messages (or vice-versa) so that theuser can view prior communication between himself or herself and othersregarding a particular project. Alternatively, the sub-menu 1582 mayallow the generation of so-called ‘threaded’ email discussions thatdisplay all messages in chronological order that are considered relatedto a subject.

The sub-menu 1582 may also allow the user to search through the subsetof messages in the messaging area 1580. For example, the sub-menu 1582may provide a ‘search messages’ option that displays a foldoutsubstantially similar to the associated search interface 13C100described previously with regard to FIG. 13C to allow the user to searchhis or her message subset.

Using this functionality, the user could search the displayed messagesthat contain certain text strings and/or were sent within a particulartimeframe.

Each message within the set of messages 1584 ₁ to 1584 _(N) includes asender, a receiver, a subject line, a sent date/time stamp, a receiveddate/time stamp, message content and possibly an attachment (e.g., afile or audio message). Certain of this information (or a summarythereof, in the case of message content) can be displayed in themessaging area 1580 to allow the user to quickly review the list ofmessages and identify those of interest, importance and/or relevance.

In another non-limiting embodiment, the sub-menu 1582 may also allow theuser to customize the information that is displayed in the message area1580. For example, a user could use the sub-menu 1582 to show or hidecertain information, such as the date/time stamps that indicate when amessage was sent and/or received.

Regardless of what information is chosen by a user to appear for eachmessage in the message area 1580, clicking on that information may causerelated information to appear in an associated interface. For example,clicking on the subject title for a message may cause the messagecontents to appear in an associated interface for easier reading.Alternatively, clicking on the attachment for a message may cause theattachment to be opened in its associated application (e.g., an MP3 fileis opened in an audio player)

In another non-limiting embodiment, clicking on the sender's (orreceiver's) name listed for a particular message may cause an associatedinterface to appear that shows certain information from his or her userprofile. FIG. 15D shows a non-limiting sample of a foldout that displaysinformation extracted from the user profile of Jean Gagliardi in anassociated interface.

By displaying such information in associated interfaces/foldouts, themessages displayed within the messaging area 1580 remain available forreview, rather than being covered by other windows or frames containingrelated content. This may simplify navigation between messages (as wellas associated message content, information about the sender/receiver andpossibly message attachments) for the user.

FIG. 15E shows a non-limiting embodiment of the community UI element1480 comprised within the UI 1430. The community UI 1480 is comprised ofa menu 1590 and a community activities area 1592.

The menu 1590 is substantially similar to the menus 1510, 1530, 1550 and1570 introduced previously and will be collectively described below.

The community activities area 1592 provides the user with access to aset of community activities 1594 ₁ to 1594 _(N) that may or may not berelated to one of the projects that he or she is currently working on.Activities that could be included in the set of community activities1594 ₁ to 1594 _(N) may include, among others:

-   -   managing his or her activity in one or more named groups;    -   managing the information in his or her user profile 340 _(i);    -   managing the information provided to the user community 14        regarding one or more projects in which the user is currently        participating;    -   finding a user in the user community 14 who possesses a certain        expertise, skill or qualification; and/or    -   providing some means whereby the user can share his or her        knowledge with the community, such as through so-called        ‘Communities of Practice’.

Of course, it will be appreciated that the above list of communityactivities is non-exhaustive as other possibilities exist and would fallwithin the scope of the present invention.

Of the set of community activities 1594 ₁ to 1594 _(N), it will beappreciated that certain of these activities allow the user a degree ofmanagement regarding information provided to the user community 14regarding themselves (via their user profile 340 _(i)) and/or theprojects they are working on. For example, a user may wish to providethe user community 14 at large with a first communication method ofcommunicating with him or her (e.g., his or her a publicly availableemail address), while project team members may be provided with a secondset of communication methods for communicating with the user, such aswork or cellular telephone numbers. By restricting the second set ofcommunication methods to those who are working with the user directly onhis or her projects, the user can maintain a degree of privacy from theuser community 14.

In a similar manner, the user may wish to provide the user community 14with certain first set of information regarding the projects that he orshe is working on, while those working on the project may be providedwith a second set of information that is more detailed than the first.For example, the first set of information provided by the user mayinclude the project's name, type (i.e., whether it is a commercial,industrial or residential development) and his or her role in theproject. However, the second set of information may include much moredetailed (and likely confidential) information about the project, suchas its exact location, the overall budget, the list of project teammembers (which may include suppliers) and the detailed timeline for theproject. By restricting the second set of information to only thosepeople who are working with the user on his or her projects, the usercan ensure that sensitive and/or confidential information can berestricted from potential competitors.

The set of community activities 1594 ₁ to 1594 _(N) may also provide auser with the ability to find an expert in the community. In anon-limiting embodiment, this activity may provide many of the samesearch controls 13C110 discussed previously in the context of thetargeted invitation. However, these controls would allow the user toidentify other members in the user community 14 who possess certainexpertise without necessarily inviting them to accept a role in aproject.

One use for the search controls in the set of community activities 1594₁ to 1594 _(N) may be to find people who are interested in participatingin sharing their knowledge about a particular domain of knowledge. Suchmembers may form a ‘community of practice’ whereby knowledge andexperience is pooled among its members to assist those with questionsand problems regarding a particular domain. For example, assume that acommunity of practice emerges regarding a certain LEED credit regardingpublic-transportation. A landscape architect who is trying to achievethis credit for a new development can ask for advice and/or help fromits participants when it comes to deciding how to connect a building orresidential development to the public-transportation network.

In a non-limiting embodiment, the menus 1510, 1530, 1550, 1570 and 1590comprised within the UI elements of the UI 1430 allow a user to adjustvarious informational aspects of their associated display area. Forexample, the menu 1510 may adjust information displayed in the projectsarea 1520, the menu 1530 may adjust information displayed in the eventsarea 1540, and so on.

Each menu in the set of menus 1510, 1530, 1550, 1570 and 1590 comprise aset of controls (e.g., clickable buttons or hyperlinks) that allowcertain aspects of the information presented in the associated area tobe adjusted. Aspects that may be adjusted via these menus may include:

-   -   the content (i.e., amount of information) in the associated        area;    -   the layout the information in the associated area;    -   the amount of information displayed in the associated area;        and/or    -   certain groupings of information in the associated area.

It will be appreciated that the above list is non-exhaustive as otherinformation aspects exist and would fall within the scope of the presentinvention.

In a first non-limiting example, the set of menus 1510, 1530, 1550, 1570and 1590 may provide one or more controls to allow a user to filter thetype of content within the associated area in its respective UI element.For example, the menu 1570 in the media/messaging UI element 1470 mayprovide a user with the ability to view messages corresponding to acertain event type, such as tasks versus document events. In this case,the type of content that subsequently appears in the associated area(i.e., the messages areas 1580) depends on the menu selection made bythe user.

Because this type of functionality is typically used to view differenttype of content, each control in this regard may be termed a ‘view’. Forexample, the menu 1530 in the time UI 1450 may provide controls to viewa “Tasks view”, a “Documents view”, a “To-Do view”, and a “Milestoneview” (among others) that would display task events, document events,to-do events and milestone events respectively in the events area 1540.By providing the ability to switch between such views, the menu 1530allows the user to quickly filter his or her events in the events area1540 to correspond to a particular type of event. This may save time forthe user who may otherwise be forced to review all of his or her eventsto identify a particular one.

In a second non-limiting example, the set of menus 1510, 1530, 1550,1570 and 1590 may provide one or more controls that allow a user tocontrol the layout of content within the associated area of itsrespective UI element. Such controls may allow the user to see thecontent in a different format and/or adjust the amount of contentdisplayed.

For example, the menu 1510 in the projects UI 1440 could allow a user toview projects in the time pod 1520 in different layouts, including:

-   -   as a list, where the project title 1524, summary information        area 1526 and/or graphic information area 1528 for each project        1522 ₁-1522 _(N) are organized generally vertically; and/or    -   as a table, where the project title 1524, summary information        area 1526 and/or graphic information area 1528 for each project        1522 ₁-1522 _(N) are organized generally horizontally (i.e., in        a row).

It will be appreciated that type of layouts provided by controls in themenus 1510, 1530, 1550, 1570 and/or 1590 are typically determined by thetype of information in each menu's respective associated area. Forexample, although it makes sense that projects, tasks and messages inthe UI elements 1440, 1450 and 1470 could be laid out as lists and/ortables, the same may not hold true for the team members and/or communityactivities in the UI elements 1460 and 1480 respectively. As a result,the layouts provided in the menus 1550 and 1590 may provide differentlayouts that those in the menus 1510, 1530 and 1570.

Regardless of the differences in specific layouts provided by the menus1510, 1530, 1550, 1570 and 1590, it will be appreciated that allowing auser to switch layouts may allow a user to realize certain efficienciesthat may enhance his or her productivity. For example, assume that aparticular user is currently involved with 27 projects. Further assumethat by default, the time pod 1520 in the projects UI 1440 can only showfive (5) of these projects at a time in a list view but that it can show12 projects in a table view. By allowing a user to switch the layout ofthe time pod 1520 from the list to the table layout, the user may beable to view a summary of 12 of his or her projects at a time, which mayallow him or her to identify those projects that need attention morequickly.

In a third non-limiting example, the set of menus 1510, 1530, 1550, 1570and 1590 may provide one or more controls that allow a user to adjustthe amount of information displayed in the within the associated area ofits respective UI element. This may allow a user to show more or lesscontent for each entry in the associated area.

For example, the menu 1570 in the media/messaging UI 1470 may allow auser to show or hide certain information associated with each message(e.g., an email or text message), such as:

-   -   the identification of the sender and/or receiver;    -   the subject;    -   the time and date stamps for when the message was sent and/or        received;    -   any header information (e.g., IP address of the sending email        server); and/or    -   a summary of the message, such as a 50-word précis.

Like the second non-limiting example above, adjusting the amount ofcontent displayed in the associated area allows the menus 1510, 1530,1550, 1570 and 1590 to be used to realize certain efficiencies. Forexample, a user may choose to hide the time/date stamps, headerinformation and/or summary of the message to view more email messageswithin the messages area 1580. This may allow the user to scan theentirety of his or her emails to more quickly identify a certain emailfrom the list.

In a fourth non-limiting example, the set of menus 1510, 1530, 1550,1570 and 1590 may provide one or more controls that allow a user togroup information displayed within the associated area of its respectiveUI element. This may allow a user to view relationships between contentin the associated area based on certain criteria. For example, therelationships between certain projects that constitute a portfolio inthe time pod 1520 may be identified through the menu 1510 that displaysprojects in this area in groups indicating that there is a relationshipbetween them. A control in the menu 1510 may allow the user to view theprojects within a (previously described) tree-branch format that wouldindicate at a glance which projects were, and were not, members of aportfolio, for instance.

Similar grouping strategies could be applied to the content in eachassociated area for the UI elements 1440 to 1480. For example, messagesin the messages area 1580 may be grouped by their date/time stamp(default) as well as by their respective sender, receiver, subject orrelated project and/or event (e.g., task or document). Events in theevents area 1540 could be grouped by their related project (default), aswell as by their type (e.g., task, document or milestone), status (e.g.,starting soon, in progress, completed) and/or related role (e.g.,landscape architect, public-transportation evangelist or bike rackconsultant).

The ability to group content using the menus 1510, 1530, 1550, 1570 and1590 may allow a user to organize content according to a certain type,as well as help him or her identify certain relationships that may nothave been evident before. In this way, the menus 1510, 1530, 1550, 1570and 1590 may allow a user to improve their efficiency, as well asexplore options suggested by newly discovered relationships betweenentities in the UI elements 1440 to 1480.

While the above description of the menus 1510, 1530, 1550, 1570 and 1590described several informational aspects that could be adjusted using amenu's constituent controls in detail, it will be appreciated that notevery menu in this set provides all of these abilities. In particular,the controls for each menu in the set of menus 1510, 1530, 1550, 1570and 1590 may be customized for the type of information displayed in itsassociated UI element. As a result, the set of controls available fromany two given menus in this set of menus (e.g., the menus 1510 and 1550)may differ from each other.

Respectfully returning to FIG. 14B, it may be seen that the UI 1430 alsoincludes controls 1495 and 1497 that are independent of the UI elements1440 to 1490 discussed above. These controls may be provided in the formof clickable elements (e.g., buttons or hypertext) that when clicked,provide certain functionality that will be described below

In particular, these controls provide functionality by which a user canperform certain activities including:

-   -   viewing a set of tags and their associated content;    -   performing a search of the content of the system 10 and more        specifically, of the projects database 312 and/or user profile        database 314;    -   saving and re-applying performed searches of the system 10;    -   viewing new messages received by the user;    -   ensuring that unfinished messages, tasks or events that were        started by a user in the UI 1430 are either completed or        discarded; and    -   ending the user's session with system 10 and the UI 1430.

In particular, all of the activities except for the last activity may behandled by the control 1495, which are described below. The lastactivity (i.e., logging out of the system 10) may be handled by thecontrol 1497, which is hereafter termed the logout control′. Since thepurpose of this control is self-evident, further details about its useneed not be provided here.

With reference to FIG. 14B, functionality provided by the control 1495may be sub-divided according to the following categories:

-   -   a search/history/tag control 1495A provided by a clickable        interface element labeled S/T/S in this figure;    -   an “unfinished messages, tasks and documents” control 1495B        provided by a clickable interface element labeled UM/T/D in this        figure; and    -   a new events control 1495C provided by a clickable interface        element labeled NE in this figure.

The functionality of each element in the control 1495 will be describedin detail below.

The search/tag/history (S/T/S) control 1495A may allow a user to performcertain actions, including:

-   -   view a set of tags associated with content in the system 10        relating to their projects;    -   create and perform a search of the system 10 in order to find        content of interest; and/or    -   save, manage and re-submit searches to the system 10 in order to        find new content that may be of interest since the last time the        search was submitted.

FIG. 15F shows one non-limiting example of an interface 1594 that couldbe used to access the tag functionality provided by the S/T/S control1495A. In this example, the interface 1594 is populated by a list oftags associated with the user, which may be provided by the taggingsub-module 650 described previously. In particular, the list of tagsdisplayed in this interface may include individual-user tags, projecttags and/or system-level tags for related content in the system 10.

It will be appreciated that each tag in the list of tags displayed inthe interface 1594 is a clickable element, which may be represented by aclickable button, an icon or (as in this example) text. The clickableelement may also provide an indication of the amount of associatedcontent (e.g., a numeric value) as well as an indication of when thiscontent has changed (e.g., a “NEW” icon). This indication may be used bythe user to confirm that his or her suspicions regarding relevantcontent in a topic (i.e., higher numbers being associated with broadtopics versus lower numbers being associated specific topics) and/or toidentify tags with new content.

When a user clicks on a tag title in the interface 1594, it expands toshow content associated with the tag, which is typically provided by thetagging sub-module 650. This content may be grouped or organized by thesub-module 650 for the user's convenience. For example, a tag 1595titled ‘Board of Advisors’ was clicked and is showing that its taggedcontent is grouped into projects, people and companies categories, eachof which are a clickable link.

Although the tags shown in the interface 1594 appear to apply to begenerally business-related subjects, it will be appreciated that anyitem deemed relevant and subsequently by the user (and/or by others inthe system) could appear in this list. For example, the user could tagcertain building supply items, such as various types of windows thatwere used in his or her projects. These may be tagged with a genericterm, (e.g., ‘windows’) or a term with certain technical specifications,such as “windows, double-pane glazed” or “windows, ¾-inch, triple-paneglazed, Energy-Star compliant”. By tagging these building materials sothat references to them are stored as tag titles in the interface 1594,a user can refer to them in later projects where information regardingsuch building materials may be needed.

The use of such information may be augmented if the tag-buildingexercise described above is extended beyond a single user to the system10 and/or the user community 14 in general. For example, the system 10may review and collect user-contributed information contained inprojects and events relating to a particular defined set of terms in aknowledge domain, such as building materials for the constructionindustry in general. Alternatively, the system 10 may be able to discernand tag more specific building materials, such as ¾-inch, triple-glazedEnergy-Star certified windows.

In one non-limiting embodiment, the system 10 may identify and tag thisinformation based on user input using a knowledge-building process thatwill be described below. In another non-limiting embodiment, the usercommunity 14 may identify and tag this information based on a set ofterms and/or taxonomy that is provided to and/or defined by members inthe community 14. In yet another non-limiting embodiment, certaintagging activities may be performed automatically by the system 10 whileother activities (or alternatively, review of the automated taggingactivities to correct mistakes and ensure quality) may be performed bymembers of the user community 14.

By grouping this information into categories, the mental load placed onthe user to identify relevant information associated with the tag isadvantageously reduced. Such a reduction may allow a user to select thecategory that she or he feels is most representative of the type oftagged content that is needed at the time.

For example, assume that instead of three (3) items being associatedwith the tag 1595, there were 300 items, including 25 projects, 119people, 98 building components/supplies and 58 companies. By breakingthe tagged items into these three categories, the user has a chance todecide whether the associated information that he or she is looking foris related to a project, a person, a particular buildingcomponent/supply or a company. Otherwise, the user may be forced tonavigate through all 300 items in the attempt to find the information ofinterest, which may be impractical for the user.

As presented above, the S/T/S control 1495A is used to find contentassociated with a particular tag, such as the tag 1595 in FIG. 15F.Alternatively, the control 1495, and more specifically elements in theinterface 1594 could also be used to apply a tag to content in the UI1430. For example, if a new message in the messaging area 1580 relatesto the Board of Advisors tag 1595, the tag (or a representative iconthereof) could be dragged onto the relevant message in this area inorder to create an association between the tag and the message. Thus,when the Board of

Advisors tag 1595 is subsequently opened, it may show four (4) items,including a project, a person, a company and the new message that wastagged in the media/messaging UI element 1470.

In another non-limiting embodiment, the S/T/S control 1495A may alsoprovide search functionality that allows the user to search the system10 based on certain user-supplied keywords or criteria. For example, auser could use the S/T/S control 1495A to search for all messages,events, projects, rankings and/or community-related postings related toa particular member of the user community 14. Such a search may be doneto identify whether the member is an active participant in the usercommunity 14 and/or what projects he or she has worked on in the past.

In another non-limiting example, the search functionality provided inthe S/T/S control 1595A may allow a user to search for projecttemplates, rather than for projects themselves. For example, assume auser is developing a project whose approach will be based on theintegrated design process (IDP) rather than a design-bid-build (ordesign-tender) process. In addition, assume that the user is unfamiliarwith the IDP process as she has only worked previously ondesign-bid-build and design-build approach projects. As a result, theuser would likely prefer to build her project based on an existingtemplate for IDP-based projects but has no such past projects to baseher design upon.

In order to find an IDP-related template, the user may use the searchfunctionality provided through the S/T/S control 1495A. In particular,she may choose to search for a term or keyword such as “IDP” or“Integrated Design Process” among the project templates 750 using thiscontrol. The user's search request may be passed by the control 1495A tothe projects module 302, which may then search through the projecttemplates 750 to identify those that have the related search term orcharacteristic. For example, the module 302 may find four (4) projecttemplates, two of which are for commercial developments using the IDPprocess, an IDP template for an residential development project and anunrelated template that used IDP as an acronym for “Indiana Departmentof Probation”. The user may then review the three relevant IDP-relatedproject templates to see which best suits her development project,purchase the template if necessary and then create her project usingthis template.

In another non-limiting example, the search functionality may allow auser to filter events based on criteria supplied by himself or herself.For example, assume a first user is responsible for submitting alldocumentation needed to initiate a process whereby a project may bereviewed and certified by a reviewing body, such as the InternationalStandards Organization (ISO) (e.g., documentation for an ISO 9000quality certification process). Further assume that the first user hasset up the project in the system 10 such that the drafting of each pieceof documentation required for the certification process by anotherproject team member is a documentation event.

As team members file their documentation and thus complete theirdocumentation events, the first user needs to identify how close (orfar) he or she is from having a complete documentation set. To do this,the first user uses the search functionality provided by the control1495A to filter the events related the project to see how many of thedocumentation are completed and how many remain outstanding.

It will be appreciated that the ability to filter events in this way maysave a user time in reviewing the status of the required documentationset. Otherwise, the first user would have been forced to review allevents in the project to manually identify those that are documentationevents, and then view the status of these events to see if they arestill outstanding. The time required for such a manual review(especially if repeated several times over the life of the project, asis typical for ISO 9000 certification and re-certification processes)may delay the submission of the documentation set to the certifying bodyand increase the resulting cost of the certification process.

The S/T/S control 1495A may also provide functionality that allows theuser to build a search query based on multiple criteria rather than onsingle criteria or simple keywords. As a result, a user could build acomplex query to answer very particular questions regarding theirproject, such as the status of particular portions of the project (e.g.,the progress of the electricians in wiring the 7^(th) floor of abuilding with CAT-5E network cables) or particular people/project roles.

FIG. 15H shows one possible non-limiting embodiment of a search querybuilder 1599 that could be used by a user to build and run a searchquery. A set of controls is provided along the left-hand side of thequery builder 1599 that allow the user to quickly build a query usingcertain pre-defined criteria. Non-limiting examples of such criteria mayinclude project scope (i.e., search only the current project or allprojects in which the user is participating), a particular UI element(e.g., the projects UI element 1440), an event within the selected UIelement (e.g., a timeline or project) and/or a time period when eventsare due to start and/or end.

It is worth noting that the user options provided by certain controls inthis area of the search query builder 1599 may be dynamically populatedbased on user selections in other controls. For example, the UI elementselected by the user for the Target control may cause particular eventtypes to be populated in the “What” (i.e., UI element) control.Alternatively, a user's choice to build a search tailored for onlycertain project type (such as LEED certification projects) may result inother controls in the query builder 1599 being pre-populated withtimelines, roles and/or events relating only to the user's selectedproject type. In this way, the query builder 1599 can interact with theuser to help him or her build a better query.

Another set of controls that allow the user to build a query using morespecialized criteria is provided along the right side. In particular,the user is provided with the ability to create individual conditionsfor a query based on particular terms, values and/or keywords. Forexample, the first condition of the query illustrated in FIG. 15Hrequires the project label contain the phrase “University LibraryAddition”, while the second condition requires the name of the projectowner be “Larry Smith”.

Those skilled in the art will see that the two query conditionsdescribed above are connected by a Boolean operator (AND) that requiresthat events found by the query must match both conditions (i.e., theevent's project label includes “University Library Addition” and theowner is Larry Smith), although other Boolean operators (such as ORand/or NOT) could also be used. As Boolean operators are believed to beknown in the art, no further description regarding them need be providedhere.

As the user builds and adds conditions for her or her query, a textualrepresentation of the resulting query appears in search query builder1599, which may be seen in FIG. 15H as the area marked ‘Filters’.Providing a textual representation of the query may allow a user totroubleshoot a query that is not working as expected. For example, if aquery is supposed to include certain events that are in fact beingexcluded from the set of results, the user can review the text of thequery in the Filter area to see if the query is being interpreted by thesystem 10 differently than expected.

In addition, each of the conditions described above require that aprospective event found by the query includes keywords, values or termsspecified by the user. However, it is also possible that a user couldspecify keywords, values or terms to be excluded from search results,such as finding all events that do not include the terms “UniversityLibrary Addition” and “Larry Smith”.

Furthermore, it is possible that a user could create a query with thequery builder 1599 that includes more than one specialized criteria foreach condition. For example, a user could add a second line to thesecond condition in the query builder 1599 illustrated in FIG. 15H toidentify a second project owner (i.e., someone other than Larry Smith)whose events should be included in the search results. When this queryis executed, events for Larry Smith and this specified individual thatbelong to the University Library Addition project will be included inthe search results.

Although the main function of the search query builder 1599 is to allowa user to build relevant queries for his or her own work, the builder1599 also provides the user with the ability to save and retrievequeries in order to re-run them later. For example, once the usercreates the query, he or she would use a Save control within the builder1599 (which may be represented by a button or a hyperlink) to save thequery within the system 10 with a particular name or designation. Thesaved query could then be retrieved by the user at a future date, whichwould reload that query's particular criteria and/or conditions into thebuilder 1599.

The save functionality of the search query builder 1599 described abovemay allow a user to save the query for his or her own use. However, itwill be appreciated that this is not an absolute requirement for savedqueries. More specifically, a query created within the builder 1599 maybe saved at several different levels within the system, including at anindividual level, at a group level (i.e., a query for a specified groupof users within the user community 14), at a project level (i.e., aquery for all users working on a project) and at the community level(i.e., a query that is made available to the entire user community 14).

Furthermore, the search query builder 1599 may also allow queries to besaved (i.e., associated) with certain events in the system 10. As anon-limiting example, an individual may use the query builder 1599 togenerate a query to extract information from a standard timeline eventthat he or she uses in each project. The user could then ‘save’ thequery with the timeline so that when he or she uses this timeline forthe next project, the query will be automatically available for use.

The search query builder 1599 also allows saved queries to betransferred between and/or reassigned to particular users of the system10. For example, assume that a first user (e.g., a senior projectmanager) creates the query illustrated in FIG. 15H in order to collectand review the tasks and events associated with Larry Smith'scontribution on the University Library Addition project. This first usersaves the query as “L Smith—Status Query” and assigns it to a seconduser (e.g., a junior project manager) who is responsible for LarrySmith's work. As a result, the second user can recall and re-execute thequery designed by the first user in order to monitor the status of LarrySmith's tasks on the project, even if this user's knowledge of querycreation the query builder 1599 is either limited or non-existent.

In addition, the query assignee can use the assigned query as a templatefor creating more specialized queries that may not have occurred to thequery assigner. For example, the project manager responsible for LarrySmith's work on the University Library Addition project may adjust thequery in order to see certain types of tasks assigned to Larry Smith sothat he or she can ascertain whether thisemployee/contractor/sub-contractor is being overworked.

The result set generated by a query (such as one developed using theaforementioned search query builder 1599) displays a list of events thatcan be used for the basis of a report. For example, a user can quicklycreate a report showing his or her project-related tasks for the nextday, week and month in order to keep himself or her-self on track withregards to the project. Alternatively, the user can generate a reportshowing completed events to submit with an invoice to be paid for theirwork.

The flexibility of the search query builder 1599 allows a userconsiderable latitude in the information that can be extracted from thesystem 10 for a report. However, the generation of reports from thesystem 10, and more specifically from the Project database 302 and theUser Profile database 314, is not altogether dissimilar from thereporting functionality provided by other database systems. Because itis believed that such reporting functionality is well-known in the art,further description and/or examples need not be provided here.

In addition, reports that are generated by a single person may be sharedwith and reviewed by a group of people, not all of whom may be users ofthe system 10. For example, the project manager for an office buildingmay generate a weekly status report showing completed events for thegeneral contractor and the bank executive responsible for the project'sfinancing. Although the general contractor may be a user of the system10, the bank executive might not be.

To allow the distribution of reports to users outside of the system 10,reports generated via query results can be exported in other fileformats, such as Microsoft Word or Excel files. In this case, theproject manager and/or general contractor could generate the weeklystatus report as an Excel spreadsheet that is sent to the bankexecutive.

The S/T/S control 1495A may also provide a history feature that recordsall searches performed by a user, as well as provides the user with theability to save and re-submit searches to the system 10. For example,assume that a user create a search using the search functionality in theS/T/S control 1495A that shows him only a certain type of event (e.g.,tasks) which will be due in the coming week (7 days). Rather than havingto recreate this search in the S/T/S control 1495A every week, the usermay save the search in the history feature with a descriptive title(e.g., “My coming week tasks”) that allow him to simply resubmit thesearch on a weekly basis. Being able to save searches in this way allowsa user to save time as he or she does not need to recreate the searchcriteria each time.

Alternatively, the history feature in the S/T/S control 1495A may alsobe used in an auditing context. For example, certain events performed bythe user in the system 10, such as the acceptance of a role, completionof a task, sending of a message or accessing of a file for a documentevent may be recorded by the system 10. In certain cases, thisinformation may be provided by the S/T/S control 1495A to allow a firstuser to review the activities performed by the same user, or morelikely, by another user who reports to the first user.

During normal use of the system, a user may perform a variety ofactivities via the UI elements 1440 to 1490 described above. Forexample, the user may review his or her projects in the projects UIelement 1440, identify and/or update certain tasks or events in the TimeUI element 1450, create and/or respond to messages in themedia/messaging UI element 1470, and contribute his or her knowledge toa community of practice in the Community UI element 1480.

Although the user may perform a plurality of activities, it is possiblethat work on certain of these activities may be interrupted or postponedas a result of a planned or unplanned interruption. For example, a usermay be working on creating sub-tasks for a task when he or she isinterrupted by a telephone call. Alternatively, the user may begin workdrafting an email to a project team member when he or she is called awayto a meeting or site visit. In such cases, there is a likelihood thatthe user will forget that he or she started on such an task or activitybefore being interrupted or called away.

To protect the user against such interruptions to his or her work, thesystem 10 provides the so-called ‘Unfinished Messages, Tasks andDocuments’ (UM/T/D) control 1495B in the control 1495. In general, theUM/T/D control 1495B displays the number of unfinished tasks messages ordocuments that the user has started in the system 10 but has notcompleted, such as marking a task as being ‘DONE’ via the adjustmentcontrols 1546.

Like the S/T/S control 1495A, the UM/T/D control 1495B is a clickableelement (such a button or hyperlink) that displays an interface whenused. FIG. 15G shows a non-limiting example of an interface displayed byuse of this control.

In particular when the UM/T/D control 1495B is used, an interface isdisplayed that shows a set of expandable event indicators 1596. Eachindicator in this set represents one task, event or message that theuser begun or opened that has not yet closed or sent. The indicators inthe set 1596 may be presented as icons, as shown in the FIG. 15G.Clicking one such icon displays an interface 1598 that is broadlysimilar to the interface used in the UI element for the task, event ormessage. For example, the unfinished message represented in theinterface 1598 includes a subject heading, a field for the recipient(i.e., the “To:” field), a field for the entry of text and a Send buttonto send the message (and subsequently remove it from the number ofunfinished tasks, events and/or messages represented by the valueassociated with the UM/T/D control 1495B)

In the non-limiting example shown in FIG. 15G, each unfinished task,event and/or message in the interface 1597 was represented by aclickable icon. However, alternative ways of representing these itemsmay be associated with the UM/T/D control 1495B, including text entriesin a so-called ‘crawl’ that would appear along the top, bottom or sideof the UI 1430.

The New Events (NE) control 1495C may be used to indicate to the userany newly arrived messages, which may include recently assigned tasksand/or events. As with the UM/T/D control 1495B, the NE control 1495C isa clickable element (such a button or hyperlink) that displays aninterface when used. In particular, the use of this control may displayan interface that is broadly similar to the interface 1596 illustratedin FIG. 15G. However, this interface would display new events, such asunread messages, timelines and/or tasks, rather than those which arecurrently considered unfinished or not completed. Since the interface1596 has already been described in the context of the UM/T/D control1495B, no further discussion of this interface need be provided here.

As described above, use of the controls 1495A, 1495B and 1495C eachcontrol the display of a particular interface, non-limiting examples ofwhich are respectively illustrated in FIGS. 15F and 15G. It will beappreciated that the interfaces displayed through the use of thesecontrols are relatively independent of the other UI elements in the UI1430, namely the projects UI element 1440 through the community UIelement 1480.

In one non-limiting embodiment of the controls 1495 (and morespecifically the three controls comprised within the above), the use ofthis control may dictate the placement of the associated interfacerelative to the UI 1430 in addition to displaying the interface. Forexample, clicking the S/T/S control 1495A may display the interface 1594described previously, as well as identify where relative to the UI 1430this interface appears.

In a non-limiting example, the first click of the S/T/S control 1495Amay display the interface 1594 at or around the left-side of the UI1430, a second click of this control may display the interface 1594 ator around the right-side of the UI 1430, while a third click of the samecontrol may hide the interface 1594 altogether. Controlling the displayof the associated interface in this way allows the user to quickly learnand control the display and placement of the interface associated withany of the controls 1495A, 1495B and/or 1495C.

For example, the user may choose to display the interface 1594associated with the S/T/S control 1495A along the left-hand side of theUI 1430 while displaying the interface 1596 for the UM/T/D control 1495Balong the right-hand side of the UI 1430. Furthermore, the user couldchoose to keep the interface (not shown) associated with the NE control1495C hidden until such time that he or she is ready to review these newevents.

Those skilled in the art will also appreciate that the cycling actiondescribed above could apply to any associated interface that isdisplayed relative to the UI 1430, including alternative embodiments.For example, if the unfinished messages were initially displayed in acrawl, clicking the UM/T/D control 1495B a first time may cause thecrawl to appear along the top of the UI 1430 (such as between thecontrols 1495 and 1497), while a second click of the same control maycause the crawl to appear along the bottom, below the UI elements. Athird click of the same control may cause the crawl to disappearentirely from the UI 1430. By combining the display of the interfaceassociated with the control with the ability to place this interface onthe UI, the user is relieved of having to perform these actionsseparately (i.e., display the control and then place the resultinginterface on the UI), which may improve the overall efficiency andproductivity of the user.

FIG. 16 shows a flowchart that provides a non-limiting example of aprocess by which the system 10 may be used to perform tasks related toprojects, as well as to allow communication and collaboration betweenusers in the user community 14.

At step 1610, the user logs into the system 10 via the authentication UI1410. In particular, the user enters his or her authenticationcredentials (e.g., email address and password) in the fields 1412 and1414 described previously and then clicks the login control 1416.

The system 10, and more specifically, the community management module304 compares the user's supplied authentication credentials againstthose stored in the user profile 340 _(i) for the user. If these match,the user is logged into the system 10. Otherwise, the user is promptedto re-enter his or her credentials in the fields 1412 and 1414.

Once the user is logged into the system 10, the user interface 1430 istypically displayed with the previously described UI elements 1440 to1490 available to the user within this interface. The UI 1430 generallyremains available until the user chooses to log out of the system atstep 1660, which is described below.

Although the intermediate steps between these two terminal points arepresented in sequential order, it will be appreciated that this sequenceonly represents one non-limiting process showing how the system 10 maybe used by a user. In other possible processes, the actions representedby these steps may occur in a different sequence and/or occursimultaneously, and certain steps may be omitted altogether.

At step 1620, the user reviews his or her projects, scheduled eventsand/or messages using the relevant UI elements in the user interface1430. In particular, the user's review may include (among others):

-   -   a review of the current status of his or her projects in the        projects UI element 1440;    -   a review of his or her scheduled events and tasks in the time UI        element 1450; and/or    -   a review of communications from (or to) other users or named        groups (e.g., those on project teams or in the user community        14).

Since use of the UI elements 1440, 1450 and 1460 has been discussedpreviously, further details of how a user may perform this step usingthese elements need not be provided here.

Based on this review, the user can assess what work identified by thesystem 10 (which may include tasks, meetings, communications, travel orother events) he or she can and/or should work on. In addition, the usermay also determine what work identified by the system 10 that can and/orshould be postponed or reassigned to another user.

At step 1630, the user organizes his or her work using the elements inthe user interface 1430. For example, the user may choose to jog thedate for certain tasks ahead by a week to allow certain other(potentially inter-dependent) tasks to be completed. For example, if atask for a user includes producing a three-dimensional animatedwalkthrough of a building but the computer-assisted design (CAD) filesare not completed, the user may choose to jog the date for this task toafter the estimated completion date for the CAD files.

During this step, the organization of events by the user may impact theschedule of other users in the system 10 thus affecting their ability tocollaborate on shared work. For example, the jogging of the date toproduce the animated 3D walkthrough may affect other users that may notbe immediately known to the user. Examples of such users may include thevideo producer who is scheduled to use the animation in a TV commercialfor the building project, as well as the voiceover talent who isscheduled to record the narration for the commercial.

As a result, the user can consider alternative possibilities for doingthe work represented by the events and/or make the necessaryarrangements with other users to allow the events to be moved. Forexample, the user may simply contact (i.e., send a message via themessage UI 1480) to the video producer and voiceover talent asking themif it would be OK to delay their work for a few days.

At step 1640, the user performs the work that was identified by thesystem 10 and which the user organized in the previous step. It will beappreciated that the execution of this work may occur through thefunctionality the system 10 (such as by composing and/or replying to amessage via the message UI element 1480) or may occur outside of thesystem 10 altogether (e.g., an HVAC technician travelling to a clientsite to maintain the filters in an air conditioning unit).

Regardless of whether the user's work is performed through the system 10or outside of it, it will nonetheless be appreciated that the system 10allows the user to identify his or her work to be performed (and/or workwhich can be postponed), as well as provide a platform to allow the workto be performed collaboratively with other users of the user community14.

At step 1650, the user reports on the work that he or she performedthrough the system 10. For example, the user may update the status ofcertain tasks in the time messaging UI to ‘Task Complete’ by using theDone button in the adjustment controls 1546 described previously. Byreporting to the system 10 on the work that he or she performed, theuser may produce results that include:

-   -   establishing responsibility and accountability for work        performed by the user;    -   allowing tasks for other users that are dependent on the user        performing his or her work to proceed; and/or    -   identifying to a second-party (e.g., the company or organization        employing the user) or a third-party (e.g., a certification        body) that a certain required task was performed by the user.

It will be appreciated that use of the system 10 by the user to recordthe performance of his or her work frees the user from having to recordthis work himself or herself with a second- or third-party (althoughsuch recording may still be necessary). In addition, any work scheduledfor other users that is dependent on the current user can be allowed toproceed by the system 10 instead of having to wait for the user to alertthe other users of this fact.

Moreover, the recording of work performed by all of the users working ona project team allows the generation of a general audit trail for theproject itself. The provision of such an audit trail may be necessaryfor a project to achieve and/or maintain a particular certification orcertification level.

For example, the maintenance of LEED certification for a building mayrequire the maintenance company to submit documentation showing theperformance of certain work tasks to a third-party certification body ona regular basis (e.g., annually or semi-annually). By recording theperformance of this work with the system 10, the needed documentationcan be generated from the system 10 in order to maintain the LEEDcertification of the building with the third-party certification body.

At step 1660, the user logs out of the system. In one non-limitingembodiment, the user may use a clickable control such as the logoutcontrol 1497 that indicates to the system 10 when the user is finished.

Alternatively, the system 10 may log the user out after a defined periodof inactivity, such as after 15 minutes of inactivity. In such analternate embodiment, the user may simply close the user interface 1430(or the associated application used to display this interface, such as aweb browser or smartphone application) without having to indicate to thesystem 10 that he or she is finished beforehand.

The collaboration system 10 may also be provided with certainfunctionality that allows it to review and/or learn from user actionstaken and/or contributions made during a project. More specifically, thesystem 10 may be provided with a learning facility that analyzes andidentifies certain best practices (or certain lessons to avoid) basedupon contributions made by user in the user community 14 as they work onprojects and/or perform tasks. In certain cases, this facility may allowthe system 10 to refine its existing workflow with such best practicesto benefit the users in the user community 14 who might otherwise not beaware of and/or implement such practices.

FIG. 17 shows the general process by which the system may employ such alearning facility. The learning facility includes a set of user input1710, a knowledge builder module 1720 and a set of adaptation data 1730.

The set of user input 1710 may represent data generated by users in theuser community 14 as they use the system 10. In this regard, the input1710 may include data generated by users of the community 14 during:

-   -   use of the projects module 302 and of the projects databases        312, such as those actions described earlier in relation to FIG.        13;    -   use of the community management module 304 and the user profile        database 314 the user community 14, such as those actions        described earlier in relation to FIGS. 6 and 12;    -   use of the user interfaces provided by the user interface        sub-module 910 and the associated UIs described earlier in        relation to FIGS. 9, 10 and 11, 14B and 15A to 15G; and/or    -   use of the associated controls 1495 in the UI 1430, such as the        tagging interface 1594 that may be used to apply certain tags to        projects, events or messages (among other possibilities) in the        UI elements 1440 to 1480.

The knowledge builder module 1720 may be invoked by the projects module302 to analyze the set of user input 1710 and generate the set ofadaptation data 1710. Typically, this module comprises certain logicthat allows the input 1710 to review and analyze the data comprisedwithin this dataset to identify certain relevant or noteworthy eventsthat may indicate a best practice (or lesson learned) that can becaptured and/or integrated within a workflow to improve the developmentand/or management of future projects within the system 10. Thecomposition and operation of the knowledge builder module 1720 will bedescribed in more detail below.

The set of adaptation data 1730 represents the output of the knowledgebuilder module 1720 after it has reviewed and analyzed the data from theset of user input 1710. The adaptation data 1730 may include bestpractices and/or lessons learned that were identified and/or extractedby the module 1720 during its analysis. The set of adaptation data 1730may be used by the system 10 (and more specifically, by the buildingproject module 302) to refine and improve future projects initiated bymembers of the user community 14.

FIG. 18 shows the composition of the knowledge builder module 1720. Inparticular, the module 1720 comprises an event analysis sub-module 1722,a statistical analysis sub-module 1724 and an adaptation data generatorsub-module 1726. The function and operation of these sub-modules will bedescribed with respect to the knowledge builder module 1720 will bedescribed below.

The event analysis sub-module 1722 can be used to review and sortthrough the set of user input 1720 in order to identify certain knownevents or occurrences from this incoming dataset. In a non-limitingembodiment, the sub-module 1722 may be configured with a predefined‘watch list’ of certain events that need to be identified within theinput 1720, such as that indicating the completion of a particular task.For example, the sub-module may be instructed via its watch list toidentify the completion of a milestone (task) signifying the end of thedesign phase events 810 in the projects database 312. As a result, whenthe milestone identifying the completion of all design phase events 810,for the project 710 _(i) is reached, the event analysis sub-module 1722can identify this task from the set of user input 1720 that may includeother information.

Alternatively, the event analysis sub-module 1722 may be provided withcertain functionality to filter and/or classify events in the set ofuser input 1710 based on a hierarchy or taxonomy that allows theirrelative importance to be judged. For example, assume that thesub-module 1722 is configured to identify the completion of followingevents from the input 1710 and rank them based on the followinghierarchy:

-   -   1. milestones:        -   a. completion of a milestone;        -   b. establishment of a milestone;    -   2. timelines:        -   a. completion of a timeline;        -   b. change in the status of a timeline;        -   c. establishment of a timeline;    -   3. Messages:        -   a. change in accompanying task status (e.g., from received            to accepted);        -   b. sending of a message with an associated task from one            user to another;        -   c. forwarding of a message with an associated task from one            user to another;    -   4. Documents; and    -   5. To-dos.

Based on the above classification system, the event analysis sub-module1722 is able to classify events comprised within the set of user input1710 to identify only those events included in the hierarchy. Inaddition, the sub-module 1722 is able to rank identified eventsaccording to their hierarchy level in order to determine their relativeimportance. Having the ability to perform such a ranking operation mayallow the knowledge builder module 1720 to more efficiently processevents in the set of user input 1710, since the event analysissub-module 1722 will know which events in the incoming dataset are ofrelatively higher and lower priority.

The statistical analysis sub-module 1724 can be used to performstatistical analyses upon particular events in the set of user input1710 identified by (and/or extracted from) by the event analysissub-module 1722. The sub-module 1724 may perform certain mathematicaland statistical calculations on the values represented in the identifiedevents to compare them against known values for similar events in theprojects database 312 in order to determine whether they may represent abest practice (or a lesson learned).

For example, assume that the event analysis sub-module 1722 identifiesand extracts tasks relating to the completion of construction phaseevents 820, for a particular project in the projects database 312 fromthe set of user input 1720. These extracted events are then provided tothe statistical analysis sub-module 1724 for analysis and comparison toknown completed construction phase events in the projects database 312for similar projects. The sub-module 1724 may then perform statisticalanalysis upon the values in these tasks, such as determining thevariation between each event in the construction phase events 820, andsimilar instances of the construction phase events 820 for otherprojects. Analysis performed by the sub-module 1724 upon the events mayinclude calculations of standard deviation, analysis of variance (ANOVA)and/or determination of confidence levels, among others.

For example, assume that the statistical analysis sub-module 1724analyzes the construction phase events 820, against those events in theexisting projects database 312 via an ANOVA variance analysis. Theresults of the ANOVA analysis indicate that the actual duration of thetasks in the construction phase events 820, are significantly less thanthose for similar events 820 known in the database 312. Assume thatfurther analysis of the events 820, by the sub-module 1724 indicate thatthe source of the efficiency gain is the reordering of certain tasks inthe events that remove a key dependency and therefore mitigate aparticular bottleneck that is known to affect projects of this type.

Those skilled in the art will appreciate that the statistical analysissub-module 1724 could perform any calculation (statistical or not) thatallows the determination of whether one or more extracted eventsrepresent a significant variance or deviation from those already knownto the knowledge builder module 1720 and to the system 10 in general. Itwill be further appreciated that the analysis performed by thissub-module can allow the determination of whether the significantvariance or deviation is positive in nature (i.e., represents a realizedimprovement in efficiency and/or cost-savings) or is negative in nature(i.e., represents a mistake, an inefficiency and/or a cost overrun).

Typically, events analyzed by the statistical analysis sub-module 1724whose deviation or variance from the established norm in the projectdatabase 312 are positive in nature may represent a ‘best practice’ thatcould be adopted in other projects to realize similar efficienciesand/or cost-savings. Likewise, events analyzed by the sub-module 1724that are negative in nature may represent a ‘lesson learned’ that shouldbe avoided in other projects to prevent similar mistakes, inefficienciesand/or cost-overruns from occurring. In the example mentioned above, theanalysis of the events by the sub-module 1724 indicated that areordering of certain tasks in the construction phase events 820 maymitigate a bottleneck and result in improved efficiency (i.e., a bestpractice).

While the identification of best practices and/or lessons learned by theevent analysis and statistical analysis sub-modules 1722 and 1724 may beof interest, the information gleaned from such events need to beintegrated as within the workflow provided by the system 10 in order tobe of use to the user community 14. Through such integration, users inthe community 14 may be provided with so-called ‘actionableintelligence’ that allows a user to make better decisions regarding hisor her project(s).

In this regard, the adaptation data generator sub-module 1726 can beused to convert the results from the statistical analysis sub-module1724 into data that can be integrated into the system 10, and morespecifically into the events, tasks and workflows of the projects module302. As an example, assume the analysis of the statistical analysissub-module 1724 that reordering certain tasks in the construction phaseevents 820 results in the realization of improved efficiencies isdetermined to be a useful enough best practice that it should beincorporated in all future projects of a similar type.

Once such a determination is made (which may be automatic or manuallyperformed), the adaptation data generator sub-module 1726 may generatedata that will cause the projects module 302 to reorder the sequence ofthe construction phase events 820 for all future projects of a similartype. This data is output from the knowledge builder module 1720 asadaptation data 1730.

It may be appreciated that the output adaptation data generatorsub-module 1726 (and of the knowledge builder module 1720 in general)may not cause the best practice(s) and/or lesson(s) learned to beimmediately adopted by the system 10. For example, it is possible thatcertain best practices and/or lessons learned generated by the module1720 may apply to situations that are very specific to particular rareprojects. For example, the analysis by the knowledge builder module 1720of events relating to the construction, operation and/or maintenance ofa heavily customized geothermal heating and cooling system used tomaintain volcanology equipment in a observation center that is locatedclose to an active Icelandic volcano may be so specialized that it couldnot be applied to or used by other projects.

In the above embodiment, the adaptation data 1730 generated by theadaptation data sub-module 1726 may be used by the system 10, and morespecifically by the projects module 302. In particular, the data 1730may be used to improve certain features related to the project templates750, such as the composition and/or ordering of events in one or moretemplates within the project templates 750.

However, it is conceivable that the adaptation data 1730 generated bythe knowledge builder module 1720 is not used by the system 10, butrather by a user in order to make a decision regarding a project in thesystem 10. In this case, the implementation of the adaptation data 1730is likely left up to the user's discretion.

For example, assume that several projects in the projects database 312included green roofs that were constructed on top of commercial andoffice developments in hot, semi-arid environments in the Americansouthwest region. In addition, assume the knowledge builder module 1720analyzed the user input 1710 from events related to the green roofconstruction for these projects.

The analysis (which was encoded as the adaptation data 1730) suggestedthat events in the construction phase events 820 related to installationof the green roof in this environment took an average of 4 days tocomplete, which may be 25-33% longer than the average for green roofselsewhere in the United States.

Further assume that a user who has assumed the role of ‘Green RoofConsultant’ for an office development project located in a suburb ofSanta Fe, N. Mex. is adjusting the duration of events related theconstruction of the green roof for this project in the time UI element1450. Because the user may be more familiar with constructing greenroofs in other, more temperate parts of the United States, she sets theduration of the timeline for the construction of the green roof in thisproject to 2 days, which conforms to average amount of time needed forthe construction of such a roof in her experience.

When the user enters this duration for the construction phase events 820related to the green roof, the projects module 302 may identify thatthis duration is actually 50% lower than the average amount of timeneeded to construct a green roof in this area of the U.S. (Onenon-limiting process that the project module 302 could use to determinethis discrepancy may be to compare the overall duration of the ‘greenroof’ timeline event in the construction phase events for this projectto the aforementioned adaptation data, which may be stored in the module302 or within the projects database 312, among other storage options.)When the module 302 identifies this discrepancy, it may prompt the userto revisit her original construction estimate by providing theadaptation data 1730 in a user-friendly format. For example, theprojects module may send the user a message containing a suggestion thatmight be similar to the following:

-   -   “TIP: You have estimated TWO (2) days to build a green roof.        Prior data shows that building a green roof in this environment        take FOUR (4) days on average. Please consider increasing your        estimate for this event.”

Based on the above suggestion, the user may decide to extend theduration of the timeline based on the information related to theadaptation data 1730 or she may decide to leave her estimate as-is.Regardless of her decision, it will be appreciated that by providing theadaptation data 1730 to the user in this format, the system 10 allowsher to make the final decision regarding the duration of events relatedto the construction of the green roof in this project.

This use of the adaptation data 1730 may cause the system 10 (and/or theprojects module 302) to appear to function similarly to adecision-support system. However, it will be appreciated that thecollaborative features of the system 10 (such as functionality providedby the community UI element 1480) allow the Green Roof consultant toverify and validate the system's suggestion with other members of theuser community 14. The ability to draw on collective knowledge of othersin the user community 14 via the system 10 may be of considerablebenefit to this user in deciding how she interprets and/or implementsthe adaptation data in her project.

Regardless of the estimated relevance and impact of the best practicesand/or lessons learned generated by the knowledge builder module 1720,it may be useful to store such findings for later review. FIG. 19 showsa knowledge database 1910 that may be accessed by the knowledge buildermodule 1720 and/or used to store information by this module.

The knowledge database 1910 may be comprised within the buildingprojects database 312. In this case, the database 1910 may be seen asincluding a table or set of tables within the database 312 that isaccessible to knowledge builder module 1720. Alternatively, theknowledge database 1910 may comprise a database that is separate to thebuilding projects database 312 but which is available to the projectsmodule 302, the knowledge builder module 1720 and/or the buildingprojects database 312. As with the other databases 312 and 314, theknowledge database 1910 may be co-located at the same geographiclocation or distributed geographically. In the latter case, thedatabases 312, 314 and/or 1910 (and their associated modules) may beinterconnected via a public network (such as the network 100) or aprivate network (not shown) such as a dedicated local- or wide-areanetwork described previously with respect to FIG. 2A.

The knowledge database 1910 may be thought of as comprising of a set ofknowledge blocks 1950 ₁ to 1950 _(N). Each of these knowledge blocks mayrepresent a particular result that was generated by the knowledgebuilder module 1720, such as a best practice and/or lesson learned.

Each instance of the knowledge block 1950, may comprise informationrelating to the result that caused the module 1720 to create the block1950, in the first place. In one non-limiting embodiment, theinformation saved within the knowledge block 1950, could include theparticular best practice or lesson learned, which may be represented byits adaptation data generated by the adaptation data generatorsub-module 1726.

Alternatively, the knowledge block 1950, may include related informationthat would allow the knowledge builder module 1720 to recreate orregenerate the result, including (among others):

-   -   a list (or a copy) of the events extracted by the event analysis        sub-module 1722 from the set of user input 1910;    -   the statistical functions and/or other calculations performed on        the events by the statistical analysis sub-module 1724;    -   the result(s) determined by the statistical analysis sub-module        1724 that determined the need for adapation data to be        generated; and/or the adaptation data 1730 generated by the        adaptation data generator sub-module 1726.

Regardless of the exact contents comprised within each of theinformation blocks 1950 ₁ to 1950 _(N), it will be appreciated that theknowledge database 1910 provides a means of storage for the results ofthe knowledge builder module 1720. This allows the system 10 to storeall of the best practices and/or lessons learned generated through thecontributions of its users, rather than only those which have beenconverted into actionable intelligence and integrated into the tasks,timelines and other events provided by the projects module 302.

Although the objective of the knowledge building module 1720 is toidentify best practices and/or lessons learned from the set of userinput 1710 that can be converted to actionable intelligence andimplemented via the adaptation data 1730 _(i) the storage of lessrelevant and implementable knowledge in the knowledge database 1910 mayprovide certain ancillary benefits to the system 10, and in particular,the user community 14.

For example, each of the knowledge blocks 1950, within the knowledgedatabase 1910 could include a summary of the best practice and/or lessonlearned in a user-friendly format (e.g., text comprising a briefdescription). In this way, users within the community 14 could consultthe database 1910 in order to learn from past experiences of other usersand projects via their best practices and/or lessons learned. This mayallow a user who has not yet participated in a project to learn from thecollective experience of those in the community 14.

Of course, it will be understood that consultation of the knowledgedatabase 1910 by the members of the user community 14 at large mayrequire that certain operations be applied to the contents of eachknowledge block 1950, to ensure that the privacy of the participants isrespected. For example, the inclusion of user names may be replaced withtheir generic role, such that any mention of “Bob Smith, landscapearchitect” is replaced with “Landscape architect”. Alternatively,privacy restrictions may be placed on certain knowledge blocks such thatthe full contents of (i.e., events and information relating to) anyparticular block may only be viewed by those who worked on that project;all others may only see a summary of the results represented by theblock 1950 _(i).

FIG. 20 illustrates a flowchart that represents one non-limitingembodiment of a method by which events generated and acted upon by usersin the user community 14 can be analyzed by the system 10 to generatethe adaptation data 1730.

At step 2010, one or more events (such as those within the set of userinput 1710) may be analyzed in order to identify and extract events ofimportance within the incoming dataset. This step is typically performedby the knowledge builder module 1720, and in particular, the eventanalysis sub-module 1722. Since the operation of this sub-module hasalready been described, further details regarding this step need not beprovided here.

At step 2020, one or more of the events identified and/or extractedduring the previous step is analyzed using statistical analysis. Thisstep would typically be performed by the knowledge builder module 1720,and in particular, the statistical analysis sub-module 1724. Since theoperation of this sub-module has already been described, further detailsregarding this step need not be provided here.

At step 2030, the events analyzed (or the results of the analysis)performed in the previous step are used to generate adaptation data. Asbefore, this step would typically be performed by the knowledge buildermodule 1720, and in particular, the adaptation data generator sub-module1726. Since the operation of this sub-module has already been described,further details regarding this step need not be provided here.

The adaptation data generated during step 2030 may result in theintegration of this data (i.e., implementation of the adaptation data1730) within the system 10, and in particular, the projects module 302.In addition, the performance of this step may also result in thegeneration of a new instance of the knowledge block 1950, that issubsequently stored within the knowledge database 1910. In this regard,the results of the process can be stored for later review, consultationand use by either the system 10 or by members of the user community 14.

The non-limiting embodiment(s) described above in relation to thecollaboration system 10 and its components have so far been presentedfrom the perspective of a human user of the system who is accessing thesystem 10 from a client 16. However, it will be appreciated that theuser of the system 10 need not be human and in fact, clients of thesystem 10 may be other computer systems similar to the computing device110 described above.

For example, a company who uses the collaboration system 10 may usetheir own software application to access and interact with this systemprogrammatically, rather than through the UI 1430 and its elements. Toprovide such programmatic access to the system 10 to other externalcomputer systems, an Application Programming Interface (or API) may beprovided to external organizations. The API includes certainprogrammatic commands that may be passed from an external computingsystem to the collaboration system 10 via the network 100 that allow thesystem 10 to respond as if a human user was performing certain actionsvia the UI 1430. For example, the API may allow an external computingsystem to access the projects module 302 and create a new project 710_(i) within the projects database 312 based on commands rather thanthrough the various interfaces provided through user interfacesub-module 910.

The provision of such an API may allow the organization to use their ownin-house applications for certain activities while also derivingadvantages provided through use of the collaboration system 10. Forexample, assume a particular architectural firm has developed acomprehensive energy calculator application based on their experience.Further assume that this calculator application may use certain inputsthat are available for a project in the projects database 312 to performits calculations. By using the API for the system 10, the company maycontinue to use its in-house energy calculator application while usingthe collaboration system 10 to manage its building projects andparticipate in the user community 14.

In the above non-limiting example of the API, the API was used by aclient 16 in order to retrieve information from the system 10 for anin-house application. However, it is conceivable that the same API mayalso be used to send information from the system 10 to a client 16 thatis non-human and is similar to computing device 110 describedpreviously. More specifically, the API may allow the system 10 toestablish a communications link with a client 16 that could provide ameans of sharing information (which may include messages, computer files(such as documents) and/or computing processes between these twocomputing devices.

In one non-limiting implementation, the API could provide an externalcomputer system with authentication information or data that would allowa user in the system 10 to access information stored within thatexternal system. For example, assume that through an agreement, thesystem 10 is able to provide the members of the user community 14 withaccess to certain resources of a library of a private association, suchas scanned or electronic copies of relevant books and conferencematerials relating to the construction industry, as well as electronicdatabases containing news and journal articles on construction-relatedtopics.

The library belongs to the private association and likely has legalagreements with other organizations against the general redistributionof its materials. As a result, the library content system responsiblefor the provision of these resources must somehow verify that each userrequesting access is a user who is in fact allowed to access theseresources. To provide such validation for a user of the system 10 who istrying to access these resources, the system 10 (and more specifically,the registration/authentication sub-module 610 of the communitymanagement module 304) may provide certain authentication data to thelibrary content system via the API.

Such authentication data could be in the form of an encrypted generalusername and password provided for users of the system 10, such that asingle username and password would work for the entire user community14. Alternatively, the authentication data could be provided in the formof an encrypted ‘handshake’ based on a mathematical formula that allowsthe user of the system 10 to appear to the library content system as anauthenticated user. Since it is believed that the methods for deriving,transferring and validating authentication data are well known in theart, further details need not be provided here.

It is worth noting in the above example, the entirety of the usercommunity 14 was assumed to have access to the external resources.However, it is possible that only certain users in the community 14 mayhave access to these resources, such as by purchasing a package thatallows such access. Alternatively, a user may achieve access to theseresources by freely contributing their knowledge to the community 14 insuch a way that they achieve a particular ranking or rating in theopinion of other users (e.g., a ‘Guru’ or ‘MVP’ status).

If a member of the user community 14 who does access to these externalresources attempts to access them (e.g., via the library contentserver), the system 10 provides authentication data as described abovevia the API. However, if a member of the community 14 who does not haveaccess to these external resources attempts to access them, the system10 (via the API) may either not provide any authentication data at all,or may provide certain data to the external system that indicates wherethe user originated. In the latter case, the receiving system (e.g., thelibrary content server) may provide the member with a certain restrictedlevel of access or provide the member with an opportunity to purchaseaccess at a certain price.

Although the above non-limiting implementation described how the system10 could authenticate a user to an external resource via the API, itwill be appreciated that other methods could also be used to providesuch authentication. For example, at the time the user indicates that heor she wishes to access the external resource, the system 10 could senda message (such as an email message) to a pre-defined address for theexternal resource. The contents of this message may provide the externalresource with the authentication details for the user (such as theusername and password indicated above). Upon receipt of such an email,the external resource will be made aware of the user's connection to it,and will thus be ready to allow the user access even though suchauthentication was not performed via the API.

In another non-limiting implementation of the API, the API could be usedto link a project of a first user of the system 10 with someproject-related resource provided for use by a second user of the system10. For example, assume that a user who is a software developer hasdeveloped a software application that opens the files representing thearchitectural design of a building (e.g., Autodesk® Revit® gbXML files),reviews and determines the building's energy efficiency and makescertain suggestions as to how its efficiency could be increased. Furtherassume that the application is being offered to users in the usercommunity 14 via the system 10. Because the application is proprietary,however, it is maintained on a server (much like the server 22) that isexternal to the system 10 (and more specifically, the central node 18)but is accessible via the network 100.

Next, assume that a user who is an architect wishes to submit herbuilding designs to this energy-efficiency application to see if thelatest iteration of the building is more energy-efficient that the last.Further assume that the user has saved the gbXML files representing herbuilding with a document event, and these files are likely availablefrom the projects database 312. When the user indicates that she wishesto use the energy-efficiency application via the system 10 (i.e., froman interface provided by the user interface sub-module 910 and/or in theUI 1430), the projects module 302 retrieves the gbXML files for theproject from the database 312. The module 302 may then package thesefiles according to some file format dictated by the API, such as in acompressed file (i.e. Zip or Stuff-It file) with an XML header thatdescribes the file contents.

The system 10 may then send the compressed file containing the user'sbuilding gbXML files to the external software application server via theAPI. Because the external software application was likely coded with thesystem's 10 API in mind, it is able to retrieve and confirm that thefile was received correctly. (This action may also result in a messagebeing sent by the system 10 to the user to inform her that her latestdesign iteration was submitted successfully.) The software applicationextracts the user's gbXML files, reviews and determines this iteration'senergy efficiency and makes certain suggestions (e.g., in a Word orExcel file) as to how its efficiency could be increased. The resultingfiles are recompressed into a single compressed file and sent back tothe system 10 by the external server via its API.

When the system 10 receives the compressed file from the externalserver, it may alert the user (e.g., via a message) that her energyefficiency results have returned and are available for her review. Inaddition, the system 10 may also charge the user a certain amount ofmoney for the service of using the external energy-efficiencyapplication, as well as for preparing, sending and receiving the filesassociated with this review.

In the example above, the API of the system 10 allows the user to sendhis or her gbXML files to the external software application server andreceive results from the energy-efficiency application. It will beappreciated that if the developer of the energy-efficiency applicationcharged a fee for use of this application, the system 10 would likelyassess the associated fee and charge the user accordingly on behalf ofthe developer. At the same time, the system 10 may reserve a portion ofthis fee for facilitating the connection between the user and theenergy-efficiency application.

In an alternative embodiment, the API may also allow external access tocertain data within the system 10, and more specifically, data withinthe projects database 312 and the user profiles database 314. The use ofthis data may be provided to aid external developers in developing orrefining their templates and/or applications.

For example, assume that many users of the system 10 submit theirbuilding gbXML files to the energy-efficiency application on theexternal server via the API. Further assume that the developer of theapplication has knowledge of the type of buildings being submitted tothe application, the results generated for each user by the applicationas well as the recommendations provided to the user as to how to adjusttheir building design to improve its energy-efficiency.

However, the developer likely has no knowledge regarding any adjustmentsto a particular building's design after the results and recommendationsfrom the application were returned to the user. In particular, thedeveloper may want to know if the user ended up adjusting his or herbuilding's design to implement any of the recommendations, and if so, inwhat way.

This information is stored within the system 10, likely within theproject database 312. In particular, the database 312 would containevents (and associated communications) related to the design of eachevaluated building that would show adjustments or changes caused by theresults/recommendations delivered by the energy-efficiency application.Having this knowledge could help the developer of the energy-efficiencyapplication improve the application and make it more useful.

To facilitate a flow of this information back to external templateand/or application developers, the API may be provided to allow accessto certain data within the projects database 312 and user profiledatabase 314. It is likely that data to which an external user wouldhave access would be a) anonymized to protect user privacy and b)aggregated to indicate general trends.

As a non-limiting example, assume that the API allows the developer ofthe external energy-efficiency application access to data in theprojects database 312, and more specifically, data related to eachbuilding project for which gbXML files were sent to the developer'sserver. The data that may be provided to the developer would likely beaggregate data, such as the average number of events representingdesign-related changes made to the project before the building designwas submitted and the number of design-related changes made after thedesign was submitted.

Having such an aggregate before-and-after view of projects would allowthe developer to see if the number of design changes after the buildingdesign was submitted was generally greater than those before submission.If the average number of design changes after submission is greater thanthose beforehand, the developer may infer that the results and/orrecommendations of the energy-efficiency application indeed caused somechanges to generally be made to a building's design.

In yet another non-limiting embodiment, the collaboration system 10 maybe used to help certify the results of a project (e.g., houses in aresidential development, an industrial factory, an office building, or asuburban strip mall among others) with a particular certification by acertifying body. In certain cases, the system 10 may not be used helpcertify a project's results, but rather may be used to initiate andsupport the certification process. Certifying bodies include theaforementioned ISO, the Underwriter's Laboratory (UL), the GreenBuilding Certification Institute (GBCI) and the United States Patent andTrademark Office (USPTO), among others.

In many cases, being certified by a certifying body for a particularcertification (e.g., a building being LEED certified or aquality-assurance process being certified as ISO 9000 compliant) is onlya first step in a larger process involving the retention (and/orimprovement) of the recognized certification. For example, once abuilding becomes LEED-certified, its certification may be reviewed on aregular basis. During such a review, the building may maintain itscurrent certification level, improve on its previous level or even loseits certification altogether.

Since the work required to achieve certification by a certifying body(such as being LEED-certified or achieving ISO 9001 status) typicallyrepresents a considerable investment of time, money and other resources,users who are responsible for an accredited project would generally liketo ensure that the result (i.e., a building) at least retains itscurrent level of certification, if not improve upon it to move to thenext level up.

Certain functionality of the collaboration system 10 may be used to helpthe project, and more specifically, the result of the project (which mayinclude a building or other physical construction) achieve certificationfrom a certifying body. In addition, certain functionality of the system10 may also help the project retain its certification if thecertification process includes periodic reviews.

FIG. 21 shows how the building projects module 302 may be incommunication with certain functionality of the system 10 that mayprovide certain certification functionality to a user. In particular,the certification functionality may be provided by a certificationmodule 2120 that is communication with a certification user interface(UI) 2130.

The certification module 2120 may be invoked by the projects module 302to analyze the certain information in a project to collect and/ordetermine certain information related to certification by a certifyingbody, such as those described above. Typically this module comprisescertain logic that allows input from the projects module 302 to reviewand analyze information stored in the projects database 312 related tocertification and certification.

Information that may be reviewed and analyzed for a given project in thedatabase 312 by the certification module 2120 may include, among others:

-   -   the existence of particular events related to achieving        certification, such as tasks or documentation events;    -   the status of certification events identified above; and    -   the existence of certain roles in the project related to        certification; and/or    -   the existence of certain documents related to the document        events identified previously.

Although the certification module 2120 and the building projects module302 have been presented as separate entities, this division was done forillustrative purposes. The functionality of the certification module2120 described above may be provided through the projects module 302.

As a result, users who are involved with the certifying body (such asthe Green Building Council (GBE) for LEED certification or InternationalStandards Organization (ISO) for ISO 9000/14000 certification) can usethe same system 10 that is being used by those who are managing andworking on the project that is being certified. Centralization aroundthe system 10 in this way may allow certain efficiencies to be realized,further details about which are provided below.

The certification UI 2130 is a graphical user interface that may begenerated by the user interface sub-module 910 and may appear similar tocertain of the interfaces previously discussed, such as the UI 1430. Forexample, when displayed the certification UI 2130 may appear similar tothe UI elements 1440 to 1480 in that it may have a menu (e.g., similarto the menu 1510) and/or an associated area (e.g., similar to theprojects area 1520). Alternatively, the certification UI 2130 may appearas a foldout associated with one of the UI elements 1440 to 1480 in amanner to similar to the associated interface 13C100 discussedrespectively in FIG. 13C.

The certification UI 2130 may provide a user with a means of interactingwith the certification module 2120. This UI may be comprised of a set ofclickable controls including buttons, drop-down lists, checkboxes, radiobuttons and/or text fields, among others. By using these controls, theuser can interact with the certification module 2120. For example,assume that the certification module 2120 requires a form containing anotarized copy of the certificate of incorporation for a company so thatthat a request for a certification review can be submitted to thecertifying body. Further assume that due to certain legislation, thesystem 10 was only allowed to hold a so-called placeholder (or ‘dummy’)version of this form while the final version of this form was storedelsewhere. Now, however, the final version of the form has been preparedand certified by a notary public and may therefore be submitted with therequest.

Because the system 10 only holds the dummy copy in the projects database312, the certification module 2120 cannot use this copy of the form.Instead, the user configures the certification UI 2130 to direct themodule 2120 to the location of the final version of this form containingthe notarized copy of the company's certificate of incorporation. Inthis way, the user can interact with and verify the activity of thecertification module 2120 during its certification-related activities.

FIG. 22 shows a certification parameters database 2210 that may also beincluded in the collaboration system 10 to assist with certain of itscertification certification-related activities. The database 2210 iscomprised of a set of certification parameters 2220 ₁-2220 _(N) thatgenerally represent certain information regarding or necessary for aproject to be accredited by a certifying body.

Each parameter in the set of certification parameters 2220 ₁-2220 _(N)likely corresponds to a certain aspect or component of the certificationprocess. For example, in the process wherein a home, building or otherconstruction is accredited as being LEED-certified, this set ofparameters may represent the various environmental and other ‘credits’that the project must earn in order to achieve this certification. Inthis case, the set of certification parameters 2220 ₁-2220 _(N) mayinclude the information provided by the certification body related toeach credit.

For example, assume that a LEED credit for a commercial or industrialconstruction project may be earned by installing secure bicycle storageand changing rooms in a facility for at least 5% of the building'sexpected occupants. Therefore, one or more parameters in the set ofcertification parameters 2220 ₁-2220 _(N) may represent informationrelated to this credit, such as the LEED credit value (i.e., 1 credit)and/or the documentation required by the certifying body to allow thiscredit, such as site drawings indicating the location of the securebicycle storage area and changing facilities.

In certain cases, the certification database 2210 and the set ofcertification parameters 2220 ₁-2220 _(N) may comprise information forone or a plurality of available certification programs that may beavailable for a project in the system 10. For example, the database 2210may contain certain parameters in the set of certification parameters2220 ₁-2220 _(N) related to the LEED-certification program that ismanaged by the GBCI, while other parameters may relate to various ISOcertification programs (e.g., ISO 9000 or ISO 14001) that are managed bythe International Standards Association. In this way, the certificationdatabase 2210 may support and assist the project in achieving multiplecertification objectives, which otherwise would likely occurindependently of each other and possibly require extra time andresources.

It will be appreciated that the set of certification parameters 2220₁-2220 _(N) may also include other information related to each credit inthe certification process that is not supplied by the certifying body.In particular, these parameters may include certain information derivedfrom user-generated or contributed information (such as from the userinput 1710 described earlier) that relates to the credit. Using theexample of the secure LEED credit from bicycle storage and changingrooms mentioned previously, it may be possible that one of more of theparameters 2220 ₁-2220 _(N) may provide user-contributed informationregarding this credit, including but not limited to:

-   -   suggestions and/or links to products and equipment manufacturers        that provide bicycle storage and have qualified as ‘secure        bicycle storage’ in the past;    -   questions and/or answers regarding the design of changing        facilities (e.g., is a shower is needed to qualify for the        credit or would a sink and bench be enough?);    -   links to external software applications (which could be accessed        via the API) that would analyze a site's design for a project        and determine whether it would qualify for this credit; and/or    -   a list of members in the user community 14 who are known to be        familiar with this credit (e.g., public-transportation and/or        bicycle credit consultants) and may be available to assist the        project team with this credit.

It will be appreciated that user-contributed information in the set ofcertification parameters 2220 ₁-2220 _(N), such as that described in thenon-exhaustive list described above, may or may not be provided by thecertification module 2120. In one non-limiting implementation, theknowledge builder module 1720 during its analysis of the user input 1710may identify user-contributed information relating to one or moreparameters in the set of certification parameters 2220 ₁-2220 _(N) andsubsequently update (or cause the update of) these parameters with thisinformation. In this way, the system 10 may be able to review, updateand maintain the certification database 2210.

Alternatively, this information may be contributed by the user community14 via the tagging interface 1594 that was described previously withregards to the S/T/S control 1495A. For example, a user may tag certaincontent in the UI interface elements 1440 to 1480 with a tag such as“LEED bicycle storage/changeroom credit”. When the user tags thiscontent, the system 10 may update the set of certification parameters2220 ₁-2220 _(N) in the certification database 2210 accordingly. In thisway, the user community 14 may be able to review, maintain and updatethe certification database 2210.

FIG. 23 shows a non-limiting embodiment of a process by which thecollaboration system 10 may support and assist a project in obtainingcertification or certification from a certifying body.

At step 2310, certain certification parameters in the set ofcertification parameters 2220 ₁-2220 _(N) are retrieved from thecertification database 2210 for a particular project. For example, auser may initiate the retrieval of these parameters by the certificationmodule 2120 via controls in the certification UI 2130. Alternatively,the certification module 2120 may retrieve these parametersindependently of the user in response to certain information or commandsbeing received from the projects module 302, such as the indication thata certain event in a project has been completed.

The certification parameters retrieved from the set of certificationparameters 2220 ₁-2220 _(N) at this step generally relate to thecertification or certification that the project is trying to achieve,which may be defined by the project's type stored in the projectsdatabase 312. For example, if a project represents a new office buildingdevelopment that is intended to be LEED-certified, the certificationparameters retrieved would typically be related to achieving LEEDcertification for a new commercial development, rather than for aresidential development or for modifications to an existing commercialstructure.

An indication of what parameters are retrieved from the certificationdatabase 2210 may also be provided by the inclusion of certain templatesfrom the project templates 750 in the project. For example, if theevents in a project for a residential development were built using aproject template that indicates that it is compliant with a certain LEEDcertification level (e.g., the LEED Canada for Homes Green BuildingRating System), the parameters from the set of certification parameters2220 ₁-2220 _(N) retrieved at this step will be related to thiscertification level.

At step 2320, the certification parameters retrieved from thecertification database 2210 during the last step are compared toexisting events in the project. This may allow the certification module2120 to identify whether the project is at a state where the certifyingbody can review it to determine whether certification can be granted (orre-granted in the case of recertification).

In a non-limiting embodiment, the certification module 2120 may comparethe status of project events with those indicated in the retrievedcertification parameters. For example, assume that certain tasks areindicated by the parameters as needing to be completed before thecertification review may begin. However, assume that upon review of theproject events by the module 2120, these tasks are identified asincomplete. In this way, the module 2120 may become aware that theproject is not at a state where the certification process can begin.

Alternatively, the certification module 2120 may compare the files (orthe state of the files) associated with project events against thoseidentified as being required by the certification parameters to see ifthe project would qualify for certification. For example, assume that acommercial project is attempting to obtain the LEED credit for thesecure bicycle storage and changing facilities identified earlier.Further assume that in order to obtain this credit, the certificationparameter indicates that project team must include the architecturaldrawings (which may be scanned blueprints or Autodesk gbXML files) thatindicate the location of the bicycle storage and changing facilities.

As a result, the certification module 2120 looks for files associatedwith the documentation event(s) related to the site design to identifyif these files exist, and if so, what state they are in. Assume that themodule 2120 finds that these files are associated with a documentationevent but are not listed as being ‘final’ (i.e., they may still bechanged) and that he location of the bicycle storage and changingfacilities are not indicated. This comparison may allow thecertification module 2120 to determine that the project would not yetqualify for this LEED credit.

It will be appreciated that the above comparison may be performed by thecertification module 2120 on a subset of related project events (e.g.,only those related to a certain LEED credit) or on all related projectevents (e.g., those related to the entire certification process). Basedon such a comparison, the module 2120 may be able to infer certainconclusions, including:

-   -   if the project is generally ready to undergo a review process by        the certifying body;    -   what events (e.g., tasks and documentation) is ready to be        compiled for the certifying body so it can begin its review and        what events are still outstanding;    -   whether the project is likely to be accredited (or        re-accredited) by the certifying body; and/or    -   if the project is likely to achieve certification, at what level        is certification likely to be provided (e.g., LEED Silver, LEED        Gold or LEED Platinum).

This information may help the project team decide whether to contact thecertifying body and initiate a review of the project. For example, ifthe certification module 2120 identifies certain documentation eventsthat are still outstanding (such as the architectural design files thatwere not finalized), the team may reorganize its work to complete theseevents. As a result, the step 2320 may incorporate several iterations ofthe comparison process described above.

It will be appreciated that at a certain iteration of the comparisonprocess described in the previous step, the certification module 2120may indicate (e.g., via the certification UI 2130) that the events inthe project seem to indicate that the project is ready for review by thecertifying body. At this time, the project team may alert the certifyingbody that it may commence a review of the project (and morespecifically, the results of the project).

It will be appreciated that the review process may be communicatedthrough the transfer of certain information between the project team andthe certifying body, including:

-   -   forms that indicate the project to be reviewed, as well as the        members of the project team who may be contacted by the        reviewers from the certifying body;    -   supporting documentation for the project to be reviewed, such as        site plans, invoices for equipment purchases and statements        regarding the installation of certain equipment; and/or    -   fees paid by the project team to the certifying body in order to        commence the review.

The information listed above is referred to here as ‘compliance data’,in that it generally allows the certifying body (and more specifically,the reviewers to be involved in the review process) to ensure that theproject is indeed ready to be reviewed. It will be appreciated that thecompliance data listed above constitutes a non-exhaustive list as otherinformation may exist that falls within the scope of the presentinvention.

At step 2330, compliance data for the project is generated. In anon-limiting embodiment, the certification module 2120 may generate thisdata based on information associated with the project events compared atthe previous step. For example, assume that the compliance data includesa set of required documentation. In this case, the module 2120 maycollect (i.e., make copies of) all required documentation files from thedocumentation events involved at step 2320 and store them in a certainlocation. Alternatively, the module 2120 may confirm from the event thatthe documentation exists and compile a checklist of documentation to begenerated.

During this step, members of the project team may use the certificationUI 2130 to help direct the module 2120 in certain aspects of thepreparation of the compliance data. For example, if certain requiredforms are not stored with documentation events in the system 10 but areavailable elsewhere (such as the notarized copy of the company'scertificate of incorporation mentioned previously), the certification UI2130 can be used to identify the location of these forms.

At step 2340, the compliance data is submitted to the certifying body inorder that the review of the project by the body may begin. It will beappreciated that in most instances, such compliance data is generallyelectronic in nature and thus may be transmitted electronically by thesystem 10, such as via its API. In this case, generation and submissionof the compliance data described in steps 2330 and 2340 may occurroughly concurrently.

In an alternative embodiment, the certifying body may have access to thecollaboration system 10, such as via the previously described API. Insuch a case, the electronic compliance data that is generated andsubmitted during the steps 2330 and 2340 may comprise programmaticmessages or commands that adjusts certain permissions applied to certainevents in the system 10, which in turn make them available to thecertifying body.

For example, assume that the compliance data typically includes a PDFcopy of a report that may be hundreds of pages long, which is typicallystored with a document event in the system. Rather than sending a copyof the PDF file to the certifying body, the system 10 may (via thecompliance data transferred using API) simply provide members of thecertifying body with permissions to the document event that isassociated with the report. In this way, the size of the compliance datasubmitted to the certifying body may be reduced considerably, as onlythe code required to provide the certifying body with the necessarypermission(s) to access the report need be transmitted.

In other embodiments, the compliance data is partially electronic andpartially physical in nature (e.g., so-called ‘hard copies’ of forms,statements, invoices and/or equipment manuals). In such cases, the datathat is electronic is prepared by the certification module 2120 andtransmitted by the system, while a list of physical compliance datarequired may be provided to the project team such that hard-copies ofthe needed forms and other documentation can be prepared and shipped tothe certifying body. In this case, the generation and submission of thecompliance data described in steps 2330 and 2340 may occur sequentially.

It will be appreciated that the certifying body may itself be using acollaboration system similar to the system 10 to organize its work. Insuch a case, the compliance data submitted during this step may be sentusing the API associated with the system 10 such that when thecollaboration system of the certifying body receives this data, its API(which may know of, if not be coded in a similar way to the API of thesystem 10) may cause certain activities to be performed automatically.Such activities may mirror those performed in the system 10, including:

-   -   project creation (i.e., the addition of the project to a list of        projects to be reviewed);    -   event and role generation (i.e., the generation of review events        and roles for reviewers for the newly-added project, which may        be based on one or more project templates);    -   project team assembly (i.e., the invitation of reviewers to take        responsibility for certain events associated with the project);        and/or    -   event monitoring (i.e., the monitoring of events associated with        the review of the project).

It will be appreciated that the above list of mirrored activities isnon-exhaustive, as other activities could be included and would fallwithin the scope of the present invention.

In another non-limiting embodiment, the collaboration system of theproject team and of the certifying body may be one and the same (i.e.,both groups use the collaboration system 10 described above). In thiscase, the performance of step 2340 may simply trigger a new set ofevents related to the certification review of the existing project inthe projects database 312, rather than involve the performance of themirrored activities described above.

In such a case, processes similar to those processes previouslydescribed with respect to FIGS. 13A and 13B may occur, albeit for thecertification review process. A brief synopsis of such a review processmay involve the creation of a review project that may be based on one ormore review templates that involve reviewer roles. The review team maybe assembled (i.e., the reviewer roles are filled) via issuing open ortargeted invitations and the project file may be stored in the projectsdatabase 312.

Furthermore, the process by which the reviewer conducts thecertification review of the project may itself be substantially similarto the process described with respect to FIG. 16. More specifically, thereview may log into the system 10 (using an authentication interfacesubstantially similar, if not identical, to the interface 1410), reviewhis or her review projects, events and messages to be completed and thenorganize his or her review events and tasks. The reviewer may thenperform the review tasks and update the related events using a userinterface that may be substantially similar to that described in FIG.14B. Once the reviewer has completed his or her work, he or she may logout of the system 10 using a logout control that may be substantiallysimilar, if not identical to, the logout control 1497 describedpreviously.

It will be appreciated that because the project team and the reviewersare using the same components of the collaboration system 10 (namely,the projects module and database 302 and 312, as well as the communitymanagement module 304 and the user profile database 314, among others)the reviewer only needs to be granted permission to access the projectin order to begin his or her review process. Once such permission isgranted, the reviewer may be seen as becoming a de-facto member of theproject team, with similar rights to access the events associated withthe project as other team members.

It may be recalled that in a previous non-limiting example, suchpermission(s) were provided via the generation and/or submission ofcompliance data between the system 10 and the system of the certifyingbody. In this case, however, the compliance data represents the grantingof certain permissions for accessing project events to the reviewersfrom the certifying body. Therefore, simply generating the compliancedata may be sufficient for the reviewers to begin the review process andsubmission of such data to the certifying body becomes moot.

It is possible that the non-limiting scenario discussed above may allowthe reviewer to collaborate with the one or more members of project teamduring the review process. For example, if the reviewer did notunderstand a how a certain task event was performed or validated, he orshe could send a message (e.g., via the media/messaging UI 1470) to theproject team member who was responsible for this event. In this way, thetime of the reviewer (who is likely responsible for a plurality ofprojects) may be better used and the certification process may be mademore efficient overall.

The above non-limiting embodiments show how both the project team andreview team may use the system 10 in substantially similar ways and toachieve similar objectives. In this way, the process by which a projectis designed, organized and maintained, as well as by which it isreviewed and receives certification, may be simplified and made moreefficient. Since the amount of time, money and other resources devotedto such processes are not inconsequential, the realization of suchefficiencies will likely produce cost reductions in these projects.

For example, use of the system 10 by both the project team and thecertifying body may help the latter information may assist the projectteam in identifying tasks or events that require additional attentionand/or resources before the certification process may begin. At the sametime, this information may also assist the certification body inpredicting which of the projects in the projects database 312 are closeto entering the certification process. By allowing the certificationbody to identify projects that are close to entering the certificationprocess, a more accurately prediction when certain resources (such asproject reviewers in general, or certain specialized reviewers inparticular) may be needed, as well as when and where certain bottlenecksmay appear, can be made.

In a non-limiting example, assume that a certification process requiresthe activities of a civil engineer with certain specialized knowledge,such as that regarding the efficient and environmentally-friendlydisposal of wastewater and storm water from a development. Furtherassume that the certifying body has only two (2) such civil engineers asreviewers on its permanent staff but may be able to hire another two (2)such engineers on contract as the need arises. If the certification bodycan identify from the system 10 those project that are close to enteringthe certification process, then the workload of the existing civilengineers can be estimated beforehand. Such information may also allowthe certifying body to determine whether the services of the two (2)additional contract engineers will be needed to deal with the expectedincreased workload, and if so, for how long.

Although various embodiments have been illustrated, this was for thepurpose of describing, but not limiting, the invention. Variousmodifications will become apparent to those skilled in the art and arewithin the scope of this invention.

1. (canceled)
 2. A tangible, non-transitory computer-readable storagemedium having recorded and stored thereon instructions that, whenexecuted by one or more processors of a computer system cause thecomputer system to: (A) provide an online marketplace to merchants ofdigital project templates that may be individually purchased to manageprojects; (B) receive at the marketplace a request from a remote clientcomputing device to present to the remote client computing device a listof project templates for sale in the marketplace; (C) receive from theremote client computing device a selection of a project template in thelist of project templates available for purchase; (D) receiveconfirmation of payment for the selected project template; and (E)enable use of the selected project template at the remote clientcomputing device to manage a project.
 3. A tangible, non-transitorycomputer-readable storage medium as defined in claim 2, wherein eachdigital project template including template data, describing: (A) asuccession of individual events that collectively define the project,the succession of individual events including: (i) a plurality of taskevents describing respective activities to be performed; and (ii) aplurality of document events describing respective documents associatedwith the project; (B) a plurality of roles for assignment to respectiveindividuals for managing execution of respective events of thesuccession of events; and (C) privileges associated with respective onesof the roles, the privileges defining levels of access to respectiveones of the events.